Platform for collobarative analysis of electronic records

ABSTRACT

Systems and methods are described, and an example system includes an AI enhanced multi-source health data integration logic that receives a first source electronic health record (EHR) data from a first EHR system and a second source EHR data from a second EHR system, and transforms, according to a knowledge representation schema, health-related information content of the first source EHR data and the second source EHR data to a first source transformed health data and second source transformed health data. The system includes a collaboration platform, configured to host a multi-source transformed health data database, including the transformed first source health data and the transformed second source health data, and hosts AI-enhanced, multiple level telecollaborative analyses by a plurality of participants of the multi-source transformed health data database, generating health management data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority from U.S. provisionalapplication 63/164,659, filed Mar. 23, 2021, entitled “AI-ENHANCED, USERPROGRAMMABLE, SOCIALLY NETWORKED SYSTEM OF ELECTRONIC HEALTH RECORD(EHR) SYSTEMS,” the disclosure which is incorporated by reference in itsentirety.

STATEMENT OF GOVERNMENT INTEREST

The present invention was made by employees of the United StatesDepartment of Homeland Security in the performance of their officialduties. The U.S. Government has certain rights in this invention.

FIELD

Embodiments disclosed herein generally relate to systems and methods forcollaborative analysis of electronic records including electronic healthrecords and health management.

BACKGROUND

The respective electronic health record (EHR) systems of the differentcomponents of the Department of Homeland Security (DHS), e.g., theTransportation Safety Agency (TSA), Federal Emergency ManagementAuthority (FEMA), and DHS Headquarters, have differences, e.g., insystem architecture, record standards, and user-interface, that canrender it impractical to pool collection of common-interestinformational content from any one component, e.g., the Coast Guard,with other DHS components or with third-parties, e.g., consultants,other contractors.

SUMMARY

In an embodiment, an example system provides for artificial intelligence(AI) enhanced, user programmable, and socially networked medical recordexchange, and medical and public health situation assessment andresponse management, and the example system includes a multi-sourcehealth data integration logic, configured to perform operationsincluding: receiving a first source electronic health record (EHR) datafrom a first EHR system and a second source EHR data from a second EHRsystem, transforming a health-related information content of the firstsource EHR data to a first source transformed health data, in accordancewith a knowledge representation schema, and transforming ahealth-related information content of the second source EHR data to asecond source transformed health data, in accordance with the knowledgerepresentation schema. The example system further includes acollaboration platform, coupled to the multi-source health dataintegration logic, and configured to host a multi-source transformedhealth data database that includes the transformed first source healthdata and the transformed second source health data, and host atelecollaboration among a plurality of participants, regarding a contentof the multi-source transformed health data database. The example systemalso includes a health data analysis and AI tool, hosted by thecollaboration platform, configured to generate a health management data,based at least in part on an analyzing of the multi-source transformedhealth data database and at least a portion of the telecollaboration.

In another embodiment an example system provides for sovereigntyprotective extraction and collaborative analysis of information contentof electronic health records and associated medical and public healthsituation assessment. Features of this example system include aninformation extracting, sovereignty protective wrapping logic,configured to perform operations including receiving an electronichealth record (EHR) data from an EHR system, and wrapping, in an EHRsystem-specific sovereignty protective wrapper, a genericized form of ahealth-related information content of the EHR data. Features of thisexample system also include a staging database, coupled to theinformation extracting, sovereignty protective wrapping logic, andconfigured to store, in accordance with the EHR system-specificsovereignty protective wrapper, the genericized form of thehealth-related information content of the EHR data. Features of thisexample system also include a transform and concept alignment logic,coupled to the staging database, and configured to perform atransforming of the genericized form of the health-related informationto a transformed interoperable health-related data; and include acollaboration platform, coupled to the transform and concept alignmentlogic, and configured to perform a hosting of a telecollaborativeanalysis of the transformed interoperable health-related data. In theexample system, features of the hosting include a wrapping, in atelecollaboration participant specific sovereignty protective wrapper, atelecollaboration data associated with telecollaboration participant,and a maintaining during the telecollaborative analysis of thetransformed interoperable health-related data, a sovereignty of thetransformed interoperable health-related data in accordance with the EHRsystem-specific sovereignty protective wrapper, and a sovereignty of thetelecollaboration data associated with the telecollaboration participantin accordance with the telecollaboration participant specificsovereignty protective wrapper.

Other features and aspects of various embodiments will be understoodfrom reading the following detailed description in conjunction with theaccompanying drawings. This summary is not intended to identify key oressential features, or to limit the scope of the invention, which isdefined solely by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of an example system-of-systems forartificial intelligence (AI) enhanced medical record exchange and commonplatform collaboration based medical and public health situationassessment, and health services resource and response management inaccordance with one or more embodiments.

FIG. 2 shows by annotation of FIG. 1 a logic flow of data pipelineaspects and concept and model pipeline aspects, and of actionableinformation in various systems and methods for AI enhanced medicalrecord exchange and common platform collaboration based medical andpublic health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 3 is a functional block diagram of an example implementation of thecombined staging database block in the FIG. 1 system and other systemsand methods for artificial intelligence enhanced medical record exchangeand common platform collaboration based medical and public healthsituation assessment, and health services resource and responsemanagement, in accordance with one or more embodiments.

FIG. 4 is a logic flow diagram of an example process in sovereigntyprotective transferring of data into and out from the combined stagingdatabase of the FIG. 1 system, for various systems and methods forartificial intelligence enhanced medical record exchange, medical andpublic health situation assessment and health service resource andresponse management, in accordance with one or more embodiments.

FIG. 5 is function block diagram of an example implementation of avirtual data warehouse and collaboration platform function block for theFIG. 1 system and various other systems and methods for artificialintelligence enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management, in accordance with oneor more embodiments.

FIG. 6 shows by graphic overlay on FIG. 5 an example generalconfiguration of a multi-participant telecollaboration that can behosted on a common platform aspect of systems and methods for artificialintelligence enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management in accordance with oneor more embodiments.

FIG. 7 is a diagram illustrating an example configuration of a softwaredevelopment kit (SDK) for multi-contributor maintenance of a multi-toolsuite of analysis apps, with an example plurality of analysis apps, thatcan be an AI enhanced multi-tool analysis resource for coupling to amulti-institutional knowledge database, for the FIG. 1 system andvarious other systems and methods for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

FIG. 8 is a diagram illustrating an example configuration of the curatedapplications block of the FIG. 1 example system, with a representativeplurality of third party and user contributed applications, for the FIG.1 system and various other systems and methods for AI enhanced medicalrecord exchange and common platform collaboration based medical andpublic health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 9 is a diagram illustrating an example configuration of thegraphical user interface (GUI) block of the FIG. 1 system, with arepresentative plurality of widgets and other features, for the FIG. 1system and various other systems and methods for AI enhanced medicalrecord exchange and common platform collaboration based medical andpublic health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 10 is a functional block diagram of an example adaptation of theFIG. 1 system, showing incorporation of the staging databaseconfiguration of FIG. 3, and the FIG. 4 diagrammed flow of sovereigntyprotective transferring of data into and out from the combined stagingdatabase, for various systems and methods for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

FIG. 11 shows, by graphic overlay of flow arrows on FIG. 10, datapipeline aspects and certain concept and model pipeline aspects, andflow of actionable information and decisions, for the FIG. 10 system andother systems and methods for artificial intelligence enhanced medicalrecord exchange and common platform collaboration based medical andpublic health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIGS. 12A and 12B show a two-sheet arrangement of a functional blockdiagram and supported process flow diagram of another example system inaccordance with one or more embodiments for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

FIGS. 13A and 13B show a two-sheet arrangement of a functional blockdiagram and supported process flow diagram showing aspects of an examplesystem in general accordance with the FIG. 10 system for medical andpublic health service resource and response management via AI enhancedmedical record exchange, feeding concept generation and dynamic updatingof multi-institutional knowledge database coupled to AI enhancedmulti-tool analysis resources in accordance with one or moreembodiments.

FIG. 14 is a process flow diagram showing certain features and aspectsshown in FIG. 13A and elsewhere in this disclosure, for AI enhancedmedical record exchange and common platform collaboration-based medicaland public health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 15 is a process diagram, with annotation showing processinter-block flows, for an implementation of an example process accordingto methods for AI enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management in accordance with oneor more embodiments.

FIG. 16 shows a process flow diagram of an example implementation ofmultiple external source data receiving and input processing, and anexample information extraction, transformation, and document sovereigntywrapper processing in the FIG. 15 process for methods for AI enhancedmedical record exchange and common platform collaboration based medicaland public health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 17 shows a process flow diagram of an example implementation 1700of combined staging database processing in the FIG. 15 process formethods for AI enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management in accordance with oneor more embodiments.

FIG. 18 shows a process flow diagram of an example implementation oftransform and concept alignment processing in the FIG. 15 process formethods for AI enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management in accordance with oneor more embodiments.

FIG. 19 shows a process flow diagram of an example implementation of theFIG. 15 transformed, interoperable data processing for AI enhancedmedical record exchange and common platform collaboration based medicaland public health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 20 shows a process flow diagram of an example alternative orfurther implementation of multiple external source data receiving andinput processing, for the FIG. 15 process in methods for AI enhancedmedical record exchange and common platform collaboration based medicaland public health situation assessment, and health services resource andresponse management in accordance with one or more embodiments.

FIG. 21 shows a process flow diagram of an example alternative orfurther implementation of the transform and concept alignment processingin the FIG. 15 process, in methods for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

FIG. 22 is a functional block schematic of an example implementation ofa computing system on which aspects of the present disclosure can bepracticed.

FIG. 23 shows a schematic view of the system.

FIG. 24 shows a schematic view of the collaboration platform.

FIG. 25 shows a schematic view of the access interface.

FIG. 26 shows a schematic view of data flow in an embodiment of thesystem.

FIG. 27 shows a schematic view of data flow in an embodiment of thesystem.

FIG. 28 shows an embodiment of the phenotype engine.

FIG. 29 shows a schematic view of the data modeler.

FIG. 30 shows an example of a sovereignty wrap.

FIG. 31 shows an example of a nested sovereignty wrap.

FIG. 32 shows a schematic diagram of the data modeler with detailsremoved to show the entire modeler in one figure.

DETAILED DESCRIPTION

In the drawings, like reference numerals designate identical orcorresponding parts throughout the several views. The drawings aregenerally not drawn to scale unless specified otherwise or illustratingschematic structures or flowcharts. As used herein, the words “a,” “an”and the like generally carry a meaning of “one or more,” unless statedotherwise.

In one example environment, a multi-source health data integration logicreceives electronic health record (EHR) data from a plurality ofdifferent EHR data sources. Two or more of the EHR data sources may bemutually independent EHR management systems. The mutually independentEHR management systems may have respectively different architectures,may use respectively different file standards, and may have respectfullydifferent configurations for user interface. The mutually independentEHR management systems can be respective EHR management systems ofdifferent components of a governmental organization, such as but notlimited to the DHS. The mutually independent EHR management systems canbe respectively different systems used by different private entities, orby different countries' governmental entities.

The multi-source health data integration logic's receiving of the EHRdata from the mutually independent EHR management systems can betransparent to the different systems' users.

In an example environment, the multi-source health data integrationlogic can receive provenanced data, which can define, as well asselectively adapt and modify, data provenance rules from the various EHRmanagement systems. The multi-source health data integration logic canthen extract health and health related information for the EHR datareceived from the different EHR management systems and, using thereceived data provenance rules, wrap the extracted health and healthrelated information in provenance rule compliant sovereignty wrappers,and store the wrapped health and health related information in a stagingdatabase. In an embodiment, the staging database can be configured tofunction as a data lake, which can feed a common platform and a multipleparticipant telecollaboration that can be hosted by and monitored orsensed by the common platform.

The common platform, the user interfaces to the common platform, as wellas participant selection processes, and various resources supporting thecommon platform can be configured to a progression or evolution to whatcan be a target population and population makeup. The configurations canbe such that the target population makeup can include, for example,participants of different skill sets, different individual andorganizational positions, participants with access to different kindsprocessing resources. Configuration of common platform architecture, theuser interfaces, and various processing resources can be for individualsas participants, and for organizations, formal or informal, private orgovernmental, as participants.

Embedded in or coupled to the common platform monitoring and sensingresources can be logic configured to construct, and dynamically updatewhat can be “virtual institutional knowledge database,” based on thesensed telecollaboration dynamics, e.g., inter-participant exchanges,analyses by individual participants, and analyses by groups ofparticipants. The analyses can include, for example, neural networks.

An example system in accordance with one or more embodiments for AIenhanced, user programmable, socially networked medical record exchange,and medical and public health situation assessment and responsemanagement can include a multi-source health data integration logic anda collaboration platform coupled to the multi-source health dataintegration logic. The multi-source health data integration logic can beconfigured to perform operations including receiving a first source EHRdata from a first EHR system and a second source EHR data from a secondEHR system, transforming a health-related information content of thefirst source EHR data to a first source transformed health data, inaccordance with a knowledge representation schema, and transforming ahealth-related information content of the second source EHR data to asecond source transformed health data, in accordance with the knowledgerepresentation schema. In an embodiment, features of the collaborationplatform can include, but are not limited to, configuration to host amulti-source transformed health data database that includes thetransformed first source health data and the transformed second sourcehealth data, and to host a telecollaboration among a plurality ofparticipants, regarding a content of the multi-source transformed healthdata database. In an embodiment, a system can include a health dataanalysis and AI tool, which can be hosted by the collaboration platform,and can be configured to generate a health management data, based atleast in part on an analyzing of the multi-source transformed heath datadatabase and at least a portion of the telecollaboration.

In one or more embodiments, the health data analysis and AI tool can bea health data first analysis tool, and the system can further comprise apublished software development kit, interfacing to the collaborationplatform. The published software development kit can be configured tosupport a suite of health data analysis and AI tools, and the suite ofhealth data analysis and AI tools can include the first healthinformation analysis and AI tools. In an embodiment, the publishedsoftware development kit can be further configured to be accessible to aplurality of third parties, for respective contributions to the suite ofhealth data analysis and AI tools.

In one or more embodiments, the knowledge representation schema can beconfigured, the transforming the health-related information content ofthe first source EHR data to the transformed first source health datacan be configured, or transforming the health-related informationcontent of the second source EHR data to the transformed second sourcehealth data can be configured, or any combination or sub-combinationthereof, to align a concept represented by the health-relatedinformation content of the first source EHR data with a conceptrepresented by the health-related information content of the secondsource EHR data.

In one or more embodiments, the multi-source health data integrationlogic can be further configured to receive and to transform a healthcaremodel configuration data to a healthcare model transformed configurationdata, in accordance with the knowledge representation schema. In anaspect, the collaboration platform that is further configured to hostthe healthcare model transformed configuration data, and the health dataanalysis and AI tool can be further configured to generate the healthservices management data further based, at least in part, on ahealthcare model that is configured based, at least in part, on thehealthcare model transformed configuration data.

In one or more embodiments, the multi-source health data integrationlogic can be further configured to generate, for the first sourcetransformed health data, a first system sovereignty data, and togenerate, for the second source transformed health data, a second systemsovereignty data. In the one or more embodiments the collaborationplatform can be further configured to include, in the hosting themulti-source transformed health data database, or in the hosting thetelecollaboration, or both, an automated enforcement of rules ofengagement in a usage, e.g., by the telecollaboration, of thetransformed first source health data and the transformed second sourcehealth data. The rules of engagement can include a first rule ofengagement for usage, e.g., by the telecollaboration of the transformedfirst source health data. The first rule of engagement can be based, atleast in part, on the first system sovereignty data. The rules ofengagement can include a second rule of engagement for usage, e.g., bythe telecollaboration of the transformed second source health data. Thesecond rule of engagement can be based, at least in part, on the secondsystem sovereignty data.

The system may be further configured wherein the multi-source healthdata integration logic is configured to: receive at least a portion ofthe first EHR system sovereignty specification from the first EHRsystem; and receive at least a portion of the second EHR systemsovereignty specification from the second EHR system.

The system may be further configured such that the multi-source healthdata integration logic comprises: a data extraction and wrapping logic,configured to generate a first genericized health-related data and afirst metadata, based at least in part on an extracting of at least aportion of the health-related information content from the first EHRdata. The data extraction and wrapping logic may be configured togenerate a second genericized health-related data and a second metadata,based at least in part on an extracting of at least a portion of thehealth-related information content from the second source EHR data. Themulti-source health data integration logic may comprise a stagingdatabase, configured to: store the first genericized health-relateddata, the first metadata, and the first system sovereignty data, andstore the second genericized health-related data, the second metadata,and, in association with the second genericized health-related data andthe second metadata, the second system sovereignty data. Themulti-source health data integration logic may comprise a transformationlogic, configured to transform, to the knowledge representation schema,the first genericized health-related data, the first metadata, thesecond genericized health-related data, and the second metadata.

In one or more embodiments, the data extraction and wrapping logic canbe further configured to generate the first system sovereignty data as afirst sovereignty wrapper, and the first sovereignty wrapper can includea first source provenance wrapper, a first source persistent encryptionwrapper, and a first source rules of engagement wrapper. The dataextraction and wrapping logic can be further configured to generate thesecond system sovereignty data as a second sovereignty wrapper, and thesecond sovereignty wrapper can include a second source provenancewrapper, a second source persistent encryption wrapper, and a secondsource rules of engagement wrapper.

One or more configurations of the system may be configured to providesovereignty protective extraction and collaborative analysis ofinformation content of electronic health records, and associated medicaland public health situation assessment. Some configurations may include:an information extracting, sovereignty protective wrapping logic,configured to perform operations including, receiving an electronichealth record (EHR) data from an EHR system, and wrapping, in an EHRsystem-specific sovereignty protective wrapper, a genericized form of ahealth-related information content of the EHR data. The system mayinclude a staging database, coupled to the information extracting,sovereignty protective wrapping logic, and configured to store, inaccordance with the EHR system-specific sovereignty protective wrapper,the genericized form of the health-related information content of theEHR data. The system may comprise a transform and concept alignmentlogic, coupled to the staging database, and configured to perform atransforming of the genericized form of the health-related informationcontent to a transformed interoperable health-related data. The systemmay also comprise a collaboration platform, coupled to the transform andconcept alignment logic, and configured to perform a hosting of atelecollaborative analysis of the transformed interoperablehealth-related data, the hosting including: a wrapping, in atelecollaboration participant specific sovereignty protective wrapper, atelecollaboration data associated with a telecollaboration participant,and a maintaining during the telecollaborative analysis of thetransformed interoperable health-related data, a sovereignty of thetransformed interoperable health-related data in accordance with the EHRsystem-specific sovereignty protective wrapper, and a sovereignty of thetelecollaboration data associated with the telecollaboration participantin accordance with the telecollaboration participant specificsovereignty protective wrapper.

Some configurations of the system may include a published softwaredevelopment kit, interfacing to the collaboration platform, andsupporting a suite of health data analysis and AI tools, accessible to aplurality of participants, for respective contributions to the suite ofhealth data analysis and AI tools. Some configurations of the system mayinclude the information extracting, sovereignty protective wrappinglogic being further configured to receive a model data, defining a modeland, in response, perform a wrapping, in a third-party supplier modelinformation SP wrapping, a genericized form of an information content ofthe model data. Some configurations of the system may include thetransform and concept alignment logic being further configured to alsoperform: configuring the transformed interoperable health-related dataaccording to a knowledge representation schema supported by thecollaboration platform, configuring the model data according to theknowledge representation schema, and aligning a concept represented bythe transformed interoperable health-related data with a conceptrepresented by the model data.

Various methods for artificial intelligence (AI) enhanced, userprogrammable, and socially networked medical record exchange, andmedical and public health situation assessment and response managementare contemplated. Such methods may include receiving a first sourceelectronic health record (EHR) data from a first EHR system and a secondsource EHR data from a second EHR system; transforming a health-relatedinformation content of the first source EHR data to a first sourcetransformed health data, in accordance with a knowledge representationschema; transforming a health-related information content of the secondsource EHR data to a second source transformed health data, inaccordance with the knowledge representation schema: hosting, on acollaboration platform, a multi-source transformed health data database,which includes the transformed first source health data and thetransformed second source health data; hosting a telecollaboration amonga plurality of participants, regarding a content of the multi-sourcetransformed health data database; and hosting a health data analysis andAI tool, by the collaboration platform, health information analysis andAI tool, the health data analysis and AI tool being configured togenerate a health management data, based at least in part on ananalyzing of the multi-source transformed health data database and atleast a portion of the telecollaboration.

Methods of use may include interfacing to the collaboration platform apublished software development kit, supporting a suite of health dataanalysis and AI tools, the published software development kit beingaccessible to a plurality of participants, for respective contributionsto the suite of health data analysis and AI tools.

Methods of use may also include the transforming the health-relatedinformation content of the first source EHR data to the transformedfirst source health data being configured, or the transforming thehealth-related information content of the second source EHR data to thetransformed second source health data being configured, or anycombination or sub-combination thereof, to align a concept representedby the health-related information content of the first source EHR datawith a concept represented by the health-related information content ofthe second source EHR data.

Methods of use may also contain receiving and transforming a healthcaremodel configuration data to a healthcare model transformed configurationdata, in accordance with the knowledge representation schema; hostingthe healthcare model transformed configuration data on the collaborationplatform; and generating the health management data further based, atleast in part, on a healthcare model that is configured based, at leastin part, on the healthcare model transformed configuration data.

Method of use may include generating, for the first source transformedhealth data, a first system sovereignty data; generating, for the secondsource transformed health data, a second system sovereignty data; andthe hosting the multi-source transformed health data database, or thehosting the telecollaboration, or a combination of the hosting themulti-source transformed health data database and the hosting thetelecollaboration including: an automated enforcing of a first rule ofengagement in a usage, by the telecollaboration, of the transformedfirst source health data, the first rule of engagement being based, atleast in part, on the first system sovereignty data, and an automatedenforcing of a second rule of engagement in a usage, by thetelecollaboration, of the transformed second source health data, thesecond rule of engagement being based at least in part on the secondsystem sovereignty data.

Method of use may include storing a first EHR system sovereigntyspecification, corresponding to the first EHR data; storing a second EHRsystem sovereignty specification, corresponding to the second EHR data;generating the first system sovereignty data based, at least in part, onthe first EHR system sovereignty specification; and generating thesecond system sovereignty data based, at least in part, on the secondEHR system sovereignty specification.

Method of use may contain the steps of receiving at least a portion ofthe first EHR system sovereignty specification from the first EHRsystem; and receiving at least a portion of the second EHR systemsovereignty specification from the second EHR system.

Some of method of use may include: receiving a first provenance data,indicating at least an ownership of a health information content of thefirst EHR data; receiving a second provenance data, indicating at leastan ownership of a health information content of the second EHR data;generating a first genericized health-related data and a first metadata,based at least in part on an extracting of at least a portion of thehealth information content from the first EHR data; generating a secondgenericized health-related data and a second metadata, based at least inpart on an extracting of at least a portion of the health informationcontent from the second EHR data; generating the first systemsovereignty data based at least in part on the first provenance data;and generating the second system sovereignty data based at least in parton the second provenance data.

Some method of use may include generating the first system sovereigntydata as a first sovereignty wrapper, the first sovereignty wrapperincluding a first source provenance wrapper, a first source persistentencryption wrapper, and a first source rules of engagement wrapper; andgenerating the second system sovereignty data as a second sovereigntywrapper, the second sovereignty wrapper including a second sourceprovenance wrapper, a second source persistent encryption wrapper, and asecond source rules of engagement wrapper

In an embodiment, features including data curation provided by thedisclosed combination of the multi-source health data integration logic,data extraction and sovereignty protective wrapping provided by the dataextraction and wrapping logic, and multiple participant collaborationprovided by a hosted by the virtual collaboration platform can includewhat can be referenced as AI enhanced medical record exchange. Themedical record exchange feature can bring medical and contextual data,analytics, decisions, and collaboration from across multiple sourcesonto a single secure medical information platform. Features of medicalrecord exchange include multilevel, persistent, embedded cybersecurity.The cybersecurity is provided, for example, by tightly sequesteringelectronic personal health information (ePHI) and limiting access toappropriate roles, data attributes, and dynamic policies across allworkflows. The medical record exchange can track data provenancethroughout the analysis pipeline and can use persistent encryptionmethods to automate enforcement of the rules of engagement that dataowners have agreed upon.

Medical record exchange can accept the burden of data integration withminimal disruption to operations of the different source systems' users.Benefits of minimal disruption can include support, for example andwithout limitation, reaching across multiple individual components of alarge organization, each having their own individual EHR systems, forindividual operational decisions by the individual EHR systems, whiledelivering the necessary tools for evidence-based oversight, management,and coordination of medical activities across the entire organization.Medical record exchange provides, therefore, a sophisticated, usable,integration platform, without requiring a single commercial EHR for theentire organization.

Implementation can be a system of systems, agnostic to the specifics ofits source systems, but able to detect and strengthen theirinterconnections and unify them as a single information framework builtfor analysis and collaboration. The design of the medical recordexchange can leverage an array of tools of modern data science and AI tocreate functional interoperability across an organization's components'individual medical record systems, without mandating preconceivedrequirements, and thus freeing components to determine for themselveswhat tools and processes are best suited to meet their unique missionneeds.

FIG. 1 shows a functional block schematic of an example of an electronichealth record system 100 for medical and public health situationassessment and response management in accordance with one or moreembodiments. Features of the system 100, in overview, can include butare not limited to AI-enhanced medical record exchange, extraction,genericizing and storing in a staging database the health informationcontents of EHR data from a plurality of EHR systems. Further featurescan include transformation logic, which can be configured fortransforming the EHR data to a transformed EHR data, e.g., using aknowledge representation schema, and feeding the transformed EHR data tocollaboration platform supported multi-user telecollaboration, which isdescribed in more detail in later sections of this disclosure. Thetelecollaboration, as will be described include, via the platform, asuite of tools analysis for a per-project, per-case, per-task, andper-document-management. The hosted telecollaboration can furtherprovide peer review and root cause analysis and automated delivery ofrelevant information to the right person at the right time. The analysistools can include data integration, data modeling, data analysis,concept recognition, concept alignment, visualization, and decisionsupport tools.

Features can include a monitoring of telecollaboration events and, e.g.,via subscription terms, maintaining a database of participants' relevantcredentials, based at least in such features, generating amulti-institutional knowledge database. The generation can becontinuing, which can produce a dynamic updating of themulti-institutional knowledge database.

In an embodiment, the FIG. 1 system 100 can include a multi-sourcehealth data integration logic 102 configured to receive what can belarge amounts of electronic health information (eHI) carried in EHRs,from a personal health information (ePHI), in various forms and filestructures maintained by a plurality of different, mutually independentEHR systems, e.g., a first EHR system 104-1, second EHR system 104-2 . .. , and Nth EHR system 104-N (collectively “EHR systems 104”). The eHIcan include electronic personal health information (ePHI) and caninclude other non-personal health information. The EHRs can be invarious forms and file structures maintained by the different EHRsystems 104. Additional resources and particular features andcombinations thereof, described in more detail in subsequent paragraphsinclude resources supporting novel processes providing, but not limitedto, extraction and transformation to a generic form of the informationcontent and related metadata of the EHRs, and EHR system-specific,adaptable sovereignty protective wrapping of the generic transformedinformation content and related metadata. Additional features andcombinations thereof can include resources supporting novel processproviding but not limited to transform and concept alignment processesthat transform the generic form of the information content and relatedmetadata of the EHRs to a transformed interoperable data. The transformincludes conversion or transformation of the multiple sourced healthinformation and metadata to a genericized health-related data. Thegenericized health-related data can be transformed again to theinteroperable data. In an embodiment, the interoperable data can bealigned to logic structure of a virtual data warehouse and collaborationplatform, which can be configured to host, for example, multipleparticipant collaborative analyses and using platform supportedknowledge representation schema of a described in greater detail insubsequent paragraphs.

Referring to FIG. 1, in an embodiment, the multi-source health dataintegration logic 102 can be configured to receive other health andhealth-related data from additional sources 106. In an aspect, themulti-source health data integration logic 102 can be configured to alsoreceive third party model data from one or more third-party modelsuppliers 108. For purposes of description, operations and processes ofreceiving data from EHR systems 104, additional sources 106, andthird-party model suppliers 108, e.g., collection, management, andsupplying data to the multi-source health data integration logic 102, isrepresented on FIG. 1 as data curation 110.

In an embodiment the multi-source health data integration logic 102 canreceive, associated with the ePHI from the EHR systems 104, theadditional data from the additional data sources 106, and the model datafrom the third-party model suppliers 108. The multi-source health dataintegration logic can also receive source-specific permissions andconditions data from one or more of the above-identified data sources.For example, as shown in FIG. 1, the multi-source health dataintegration logic 102 can receive from the first EHR system 104-1 afirst EHR system electronic source-specific permissions and conditionsdata (labeled “PMN/Cond-1”), hereinafter referenced as “first EHRPMN/CD,” and can receive from the Nth EHR system 104-N anothersource-specific permissions and conditions data (labeled “PMN/Cond-N”),hereinafter referenced as “Nth EHR PMN/CD.” For purposes of description,permissions and conditions data received from the different EHR systems104 will be referenced collectively as “EHR permissions and conditionsdata, which will be alternatively recited as “EHR PMN/CD.”

In an embodiment, the FIG. 1 multi-source health data integration logic102 can receive, from the additional sources 106, permissions andconditions data, which is hereinafter referenced collectively as“additional sources permissions and conditions data” and, alternatively,as “ADS Data PMN/CD.” In an embodiment, the FIG. 1 multi-source healthdata integration logic 102 can receive, from the third-party modelsuppliers 108, permissions and conditions data that is hereinafterreferenced as “third party model sources permissions and conditionsdata” and, alternatively, “Third Party Model PMN/CD.”

It will be understood that in the context of the present disclosure theabove-introduced letter strings “PMD/CD,” “EHR PMN/CD,” and “ADS DataPMN/CD” are coined letter strings that serve only as reduced lettercount representations, respectively, of the word sequences“source-specific permissions and conditions data,” “EHR systemsource-specific permissions and conditions data,” and “additionalsource, source-specific permissions and conditions data,” and none ofthese coined letter strings, as used herein, possesses, imports, orapplies any intrinsic meaning.

The EHR PMN/CD received at the multi-source health data integrationlogic 102 can include, identify, reference, define, specify, and/orembody (hereinafter collectively “include”) respective EHR systemsovereignty specifications. For example, the first EHR PMN/CD caninclude a first EHR system 104-1 sovereignty specification, the secondEHR PMN/CD can include a second EHR system 104-2 sovereigntyspecification, and so forth, with the Nth EHR PMN/CD including an NthEHR system 104-N sovereignty specification. The EHR system sovereigntyspecifications received from the EHR systems 104 can in turn include,identify, reference, define, specify, and/or embody (hereinaftercollectively “include”) respective EHR sovereignty rules. For example,the first EHR system 104-1 sovereignty specification can include firstEHR system 104-1 sovereignty rules, the second EHR system 104-2sovereignty specification can include second EHR system 104-2sovereignty rules, and so forth, with the Nth EHR system 104-Nsovereignty specification including Nth EHR system 104-N sovereigntyrules.

In an embodiment the multi-source health data integration logic 102 canbe configured such that new permissions and conditions data may not berequired for each data received from the described sources. For example,the multi-source health data integration logic 102 can be configuredsuch that, prior to a given reception of EHR data from an nth EHR system104-n, an nth EHR system PMN/CD can be received and stored, and thenused for subsequent EHR-n data. In an embodiment, the multi-sourcehealth data integration logic 102 can receive updated EHR permissionsand conditions data from one or more of the EHR systems 104. In anotherembodiment, the multi-source health data integration logic 102 canreceive data with embedded identifiers of permissions and conditions,referencing an earlier received set of permissions and conditions data.

In an embodiment, the multi-source health data integration logic 102 canbe configured to store up to N different EHR system sovereigntyspecifications, and based at least in part on same, to generate, select,construct, assemble. or configure (hereinafter collectively “generate”)appropriate EHR system-specific rules. The multi-source health dataintegration logic 102 can include, for example, as translation featurethat can translate the stored EHR system sovereignty specifications toappropriate rules, protocols, and formats native to the multi-sourcehealth data integration logic 102.

In an embodiment, data ownership can be singular or multilateral, andnew ownership with additional data sovereignty rules can accrue duringdata transformational processes. In an example accrual, ownership andsovereignty rules can be nested as value of the information content isadded during data modeling.

In an embodiment, one or more of the EHR system 104 sources, or one ormore of the additional sources 106, or one or more of the third partmodel sources 108, or any combination of such sources, can provideinformation without data sovereignty rules. In an embodiment themulti-source health data integration logic 102 can be configured withone or more default sets of sovereignty rules, and with default ruleselection logic for configurations with more than one set of defaultsovereignty rules.

In an embodiment, system 100 features can include, but are not limitedto, collecting, pooling, and virtual platform supporting of collective,collaborative, and multilevel analysis of received EHR system sourcedinformation, while protecting the data sources' respective datasovereignty rules. System features for protecting data sovereignty rulescan include features of the multi-source health data integration logic102. Such features can include an information extraction and datasovereignty wrapping logic 112 and, coupled to the logic 112, a combinedstaging database 114. For brevity, the word string “informationextraction and data sovereignty wrapping logic” will be alternativelyrecited in the remainder of this disclosure as “IE-DSW logic.” It willbe understood that, as used in this disclosure, “IE-DSW” is an arbitrarycoined string that serves only as a reduced letter count representationof the word sequence “information extraction and data sovereigntywrapping,” and, as used herein, does not possess, import, or apply anyintrinsic meaning.

In an embodiment, the IE-DSW logic 112 can extract from theabove-described data received from data curation 110, e.g., extract ePHIdata from data sourced by the EHR systems 104, extract additionalinformation, e.g., additional health and health-related information,from data sourced by the additional sources 106, and extract model datafrom data sourced by the third-party model suppliers 108. In anembodiment, the IE-DSW logic 112 can also translate the extractedinformation to what can be a generic information or knowledgerepresentational language (hereinafter “generic form”). The IE-DSW logic112 can, in an embodiment, wrap the generic form information insource-specific sovereignty protective wrappers, configured to providesovereignty protection in accordance with the received rules andpermissions data described above. Example protective wrapperconfigurations, features, and aspects are described in more detail inlater paragraphs, e.g., in one or more paragraphs referencing FIG. 3. Aswill be understood from reading this disclosure in its entirety, invarious embodiments sovereignty protective features can be overarching,and can extend beyond direct operations of the wrappers applied by theIE-DSW logic 112.

In an embodiment, the combined staging database 114 can include astaging database first logic portion configured to store a stagingdatabase first portion 116 of extracted, generic transformed informationcontent of EHR data received from EHR systems 104 (which can includegeneric transformed EHR system sourced ePHI data 116-1 and generictransformed EHR metadata 116-2) and can include EHR system SPspecification data 116-3. For purpose of description, the extracted,generic transformed EHR system sourced ePHI data 116-1 will bealternatively referenced as “GTR EHR system sourced ePHI” 116-1 and thegeneric transformed EHR metadata 116-2 will be alternatively referencedas “GTR EHR metadata” 116-2.

In an embodiment, the combined staging database 114 can include astaging database second portion 118 that can store the generictransformed additional source health data 118-1, generic transformedadditional source metadata 118-2, and additional source SP specificationdata 118-3. As visible in FIG. 1, the combined staging database 114 canalso include a staging database third portion 120 that can store thegeneric transformed third-party supplier model data 120-1, generictransformed third-party supplier metadata 120-2, and third-partysupplier SP specification data 120-3.

It will be understood that the staging database first logic portion thatstores the staging database first portion 116, the staging databasesecond logic portion that stores the staging database second portion118, and staging database third logic portion that stores the stagingdatabase third portion 120 are logic delineations, which are notintended as any limitation of hardware-software implementation orallocation of functionalities, hardware or software architecture ofimplementations.

Feedback loop 122 can provide feedback of primary data requirements todata sources, e.g., EHR systems 104, additional data sources 106, andthird-party models suppliers 108.

Referring to FIG. 1, the multi-source health data integration logic 102can include a transform and concept alignment logic 124. The transformand concept alignment logic 124 can be configured to transform thecontent of combined staging database 114 first logic section, forstorage or hosting as transformed interoperable data 126, on a virtualdata warehouse and collaboration platform 128, described in greaterdetail in subsequent paragraphs. Features of and processes performed ingenerating the transformed interoperable data, including the labeledbridge between the transformed component data and the derived conceptmarket, and the respective bridges between the transformed additionalsources data and the derived concept market, the hostedtelecollaboration data and the derived concept market and thetransformed third party model data and the derived concept market, aredescribed in greater detail in reference to FIG. 5.

The transform and concept alignment logic 124 can include first logicsection 124-1 configured to align, for the collaboration platform,related concepts in the different EHR data from EHR systems 104, andsecond logic section 124-2 configured to align, for the collaborationplatform, related concepts in the different data received from theadditional sources 106, and third logic section 124-3 configured toalign related concepts in the model configuration data received from thethird-party model suppliers 108.

Tools that can be applied by the transform and concept alignment logic124 can include formal ontologies, e.g., Web Ontology Language (OWL),the National Information Exchange Model (NIEM), and other knowledgerepresentation schemata. Tools that can be applied by the transform andconcept alignment logic 124 can include non-ontological knowledgerepresentations, e.g., an integrated phenotype reference model. Toolsthat can be applied by the transform and concept alignment logic 124 caninclude standardized vocabularies, e.g., Systematized Nomenclature ofMedicine (SNOMED), AI tools such as machine learning (ML), and deeplearning (DL), and data dictionaries.

In embodiment, the system 100 can include a feedback loop 130, which canprovide feature engineering feedback from the virtual data warehouse andcollaboration platform 128 to the transform and concept alignment logic124.

In an embodiment, the system 100 can include a published softwaredevelopment kit (SDK) 132. Features of the published SDK 132 can includedistributed competition based updating of applications implementing theabove-described analysis tools. Features of the SDK 132 are described inmore detail later in this disclosure, including description in referenceto FIG. 7 of an example configuration.

In an embodiment, the system 100 can include an app market 134, whichcan provide for curated contributions from users and third parties.Various features of the app market 134 are described in more detaillater in this disclosure, including description in reference to FIG. 8of an example configuration. Such features include system-integralprotection or tendency against obsolescence, by the app market 134 andby a combination of the app market 134 and the published SDK 132, e.g.,particularly configuring the SDK 132 to promote, or inherently produce,or both, Application Programming Interface (API) supplier to APIsupplier competition.

In an embodiment the system 100 can include a Graphical User interface(GUI) 136. Features of the GUI 136 can include ready configurability,e.g., a low barrier to accessibility and easily personalized home pagewith user-added widgets. These and other features of the GUI 136 aredescribed in more detail later in this disclosure, including descriptionin reference to FIG. 9 of an example GUI implementation and anoperational configuration thereof.

In an embodiment, the system 100 can include a feedback loop 138, whichcan be configured to feed back to the virtual data warehouse andcollaboration platform 128 information regarding, for example,collaboration participants' patterns of using system 100 resources. Thefeedback loop 138 can be arranged, for example, within a combinationthat can include a monitor of the GUI 136 configured to detect GUI useinformation reflective of user patterns of using the apps on the appmarket 134 and interfaces to a form or such information or portions ofsuch information may be obtained, for example, via monitoring the GUI136.

FIG. 2 is a flow diagram showing example flows through system 100,indicated by flow arrows superposed on a copy of the FIG. 1 functionalblock diagram of system 100. The process flows include a data pipelineflow 202, representing a concept and model pipeline flow 204. Decisionpipeline flow 206 represents generation of actionable information fordecisions by end users from processes on the example system forAI-enhanced health service resource and response management inaccordance with various embodiments.

FIG. 3 shows a logic schematic of a combined staging database 300, whichcan be an example implementation of the FIG. 1 system 100 combinedstaging database 114. In an embodiment, the combined staging database300 can be configured to store the GTR EHR system sourced ePHI data116-1 and GTR EHR metadata 116-2 in a sovereignty protective wrap, andto configure the sovereignty protective wrap based at least in part onthe EHR system SP specification data 116-3. For purposes of description,recitation hereinafter of “sovereignty protective” will be alternativelyuse the following abbreviated form: “SP.” It will be understood that“SP” as used herein is a coined letter string that serves only as areduced letter count representation of the word sequence “sovereigntyprotective,” and in the context of this disclosure does not possess,import, or apply any intrinsic meaning.

Systems for AI-enhanced health service resource and response managementin accordance with various embodiments, such as but not limited tosystem 100 can, based in part on SP wrap configurations and SP wrappingprocesses disclosed herein, maintain rules of engagement with, protectsovereignty of and protect against unauthorized access to GTR EHR systemsourced ePHI data 116-1 and GTR EHR metadata 116-2. In an embodiment,the combined staging database 300 can generate or form SP wrapping witha multilayer configuration. An example multilayer SP wrappingconfiguration can comprise a three-layer wrapping such as the examplethree-layer configuration of the EHR information SP wrapping 302. Asshown in FIG. 3, the three-layer configuration of the EHR information SPwrapping 302 includes an EHR source-specific provenance layer 302-1, EHRsource-specific persistent encryption layer 302-2, and EHRsource-specific rules of engagement layer 302-3.

In an embodiment, the combined staging database 300 can also the storethe generic transformed additional source health data 118-1 and thegeneric transformed additional source metadata 118-2, collectivelyreferenced for purposes of description as “additional source generictransformed information,” with additional source information SP wrapping304. Purposes and functions of the additional source information SPwrapping 304 can be, for example. as described above for the EHRinformation SP wrapping 302 for the GTR EHR system sourced ePHI data116-1 and GTR EHR metadata 116-2, i.e., maintaining rules of engagementwith, protecting sovereignty of, and protecting against unauthorizedaccess to generic transformed additional source health data 118-1 andgeneric transformed additional source metadata 118-2. In an embodiment,configuration of additional source information SP wrapping 304 can bebased at least in part on the additional source SP specification data118-3. In an embodiment, the additional source sovereignty protectivewrap can be, but is not necessarily, a multilayer wrap configurationsuch as the examples of additional source information SP wrapping 304visible in FIG. 3. The example comprises an additional source provenancelayer 304-1, additional source persistent encryption layer 304-2, andadditional source rules of engagement layer 304-3.

With continuing reference to FIG. 3, in an embodiment the combinedstaging database 300 can store the generic transformed third-partysupplier model data 120-1 and generic transformed third-party suppliermetadata 120-2, collectively referenced for purposes of description as“third-party model information,” with third-party model information SPwrapping 306. Purposes and functions of the third-party supplier modelinformation SP wrapping 306 can be, for example. as described above forthe EHR information SP wrapping 302 for the GTR EHR system sourced ePHIdata 116-1 and GTR EHR metadata 116-2, i.e., maintaining rules ofengagement with, protecting sovereignty of, and protecting againstunauthorized access to third-party model information. In an embodiment,third-party supplier model information SP wrapping 306 can be based atleast in part on the third-party supplier SP specification data 120-3.In an embodiment, the third-party supplier model information SP wrapping306 can be, but is not necessarily, a multilayer wrap configuration suchas the examples of third-party supplier model information SP wrapping306 visible in FIG. 3. The example comprises a third-party supplierprovenance layer 306-1, third-party suppler persistent encryption layer306-2, and third-party suppler rules of engagement layer 306-3.

It will be understood that “three-layer” as used herein, in the contextof sovereignty protective wrap, can be a logic representation that isnot necessarily limiting as to any sequencing or ordering of operation.It will also be understood that certain sovereignty protective wrap(s)for the GTR EHR system sourced ePHI data 116-1 and GTR EHR metadata116-2 are not necessarily configured identically to the sovereigntyprotective wrap(s) for the generic transformed additional source healthdata 118-1 and generic transformed additional source metadata 118-2, orto the sovereignty protective wrap(s) for the generic transformedthird-party supplier model data 120-1 and generic transformedthird-party supplier metadata 120-2. It will be further understood thatnew ownership with additional data sovereignty rules can accrue duringdata transformational processes 124, and that that logic 112 can beiteratively reapplied based on feedback from logic 124 to create nestedaccrual, ownership and sovereignty rules as value of the informationcontent is added during data modeling.

FIG. 4 is a process flow diagram illustrating a flow 400 of acomputerized process, in accordance with various embodiments, forperforming SP transferring of data from the above-described externaldata sources, i.e., the EHR systems 104, additional sources 106, andthird-party model suppliers 108, into and out from the combined stagingdatabase 114. Example features and operations of the flow 400 will bedescribed in reference to the FIG. 1 system 100. This is to assist infocusing description of the flow 400 on features of the process. It isnot intended to limit practices of the flow 400 to the FIG. 1 system100. In an embodiment, features of the flow 400 can include computerizedinformation extracting and data sovereignty wrapping 402, and featuresthereof include loading into the combined staging database 114appropriately SP wrapped generic transformations of information contentof data received from the above-described external data sources. Thecomputerized information extracting and data sovereignty wrapping 402can be performed, for example, by the IE-DSW logic 112. Implementationsof the IE-DSW logic 112 include, but are not limited to, a generalpurpose programmable computer that includes a processor coupled to atangible, non-transitory storage medium that stores or embodiescomputer-executable instructions that, when executable by the processor,cause the processor to perform in accordance with the describedcomputerized information extracting and data sovereignty wrapping 402.Example implementations of the general purpose programmable computer aredescribed in more detail later in this disclosure, for example, inreference to FIG. 20.

Features of the flow 400 can also include computerized transforming andconcept aligning 404, and features thereof include aligning of relatedconcept information and transformation of such information to aninteroperable form for use, for example, by collaborative analysisresources and processes hosted by the virtual data warehouse andcollaboration platform 128, as described in more detail in laterparagraphs. The computerized transforming and concept aligning 404 canbe performed, for example, by the transform and concept alignment logic124. Implementations of the transform and concept alignment logic 124can include, but are not limited to, a general purpose programmablecomputer, such as described above for implementation of the IE-DSW logic112.

Referring to FIG. 4, in an embodiment, information extracting and datasovereignty wrapping 402 can include a first branch IE-DSW processing406, which can be for EHR system sourced ePHI data received from EHRsystems 104, a second branch IE-DSW processing 408, which can be foradditional source data received from additional sources 106, and caninclude a third branch IE-DSW processing 410, e.g., for third-partysupplier model data received from third-party model suppliers 108. Forpurposes of describing embodiments and example features and operationsthereof, the first branch IE-DSW processing 406 will be alternativelyreferenced as the “EHR source IE-DSW processing” 406, the second branchIE-DSW processing 408 will be alternatively referenced as the“additional source IE-DSW processing” 408, and the third branch IE-DSWprocessing 410 will be alternatively referenced as the “third-partysource IE-DSW processing” 410.

FIG. 4 illustrates a data lake 114 where a large volume of data has beencleaned and staged, ready for analysis, but the data are still largelyin their original form and maintain much of their original architecture.The data is in the same platform, some basic translations may have beenmade (e.g. true NULLs for a database that used “N/A”s), and securityfeatures may have been attached. With the data in the same platform, thedata modeler 1A can process the next step. The data modeler 1A may alignlike concepts that are available from within the records to generate amodel. In some cases, a model may be an integrated phenotype referencemodel (“IPRM”) (1220 on FIG. 12B).

As stated above, description of features and operations in the EHRsource IE-DSW processing 406 assumes EHR system sourced data that caninclude ePHI data and EHR metadata. Regarding EHR source SPspecifications, in accordance with various embodiments the flow 400 canreceive these specifications via EHR system 104 sourced data. Suchembodiments can include EHR system SP specification data that carriesthe SP specifications in their entirety. In other embodiments, the EHRsystem SP specification data may include an identifier of or a referenceto EHR source SP specifications that may be stored, for example, by amemory resource that can be coupled to or otherwise accessible tocomputer resources performing the EHR source IE-DSW processing 406,e.g., the above-described general purpose computer implementation of theIE-DSW logic 112. These are only examples of providing the flow 400 EHRsource SP specification information, additional source SP specificationinformation, and third-party source SP specification information to theflow 400, and are not intended as a limitation on the scope of practicesin accordance with disclosed embodiments.

In an embodiment, implementations for providing additional source SPspecifications from the additional sources 106 to the additional sourceIE-DSW processing 408, or providing third-party source SP specificationsfrom the third-party model suppliers 108 to the third-party model sourceIE-DSW processing 410 can include, for example, implementations asdescribed above for providing EHR source SP specifications to the EHRsource IE-DSW processing 406.

Referring to FIG. 4, in an embodiment, the EHR source IE-DSW processing406 can include, in response to receiving ePHI data from EHR systems104, a first branch information extracting 406A, which extracts ePHIcontent and EHR metadata from the EHR system sourced ePHI data. In anembodiment, following, merged with, or otherwise associated with thefirst branch information extracting 406A (hereinafter collectivelyencompassed by “associated with,” where explicitly stated or made clearfrom its context to mean otherwise) can be a first branch transforming406B. Features of the first branch transforming 406B can includetransforming the extracted information content of the PHI data and EHRsystem metadata to GTR EHR system sourced ePHI data 116-1 and GTR EHRmetadata 116-2. In an embodiment, EHR source IE-DSW processing 406 canalso include, associated with the first branch transforming 406B, afirst branch loading 406C, and features thereof can include loading thegeneric ePHI and generic EHR sourced metadata into, respectively, ageneric ePHI template and generic EHR metadata template. In one or moreembodiments, the EHR source IE-DSW processing 406 can also include, forexample, associated with the first branch loading 406C, a first branchsource-specific SP wrapping 406D the template loaded generic ePHI andgeneric EHR sourced metadata with an SP wrapping that complies with theEHR sovereignty specification, e.g., as defined by or referenced by EHRsystem SP specification data 116-3 included with the EHR system sourcedePHI data In an embodiment, operations in the first branchsource-specific SP wrapping 406D can include storing the SP wrappedgeneric ePHI and generic EHR sourced metadata in the combined stagingdatabase 114 in accordance with the SP wrapping.

In an embodiment, additional source IE-DSW processing 408 can be inresponse to receiving additional health data from additional sources106, and can include a second branch information extracting 408A and,for example, associated with the second branch information extracting408A, a second branch transforming 408B. In an embodiment, for example,associated with the second branch transforming 408B, can be a secondbranch template loading 408C and, associated therewith can be a secondbranch source-specific SP wrapping 408D. The second branch informationextracting 408A can include, for example, extracting health informationcontent from the additional source health data The second branchtransforming 408B can include, for example, transforming the extractedadditional source information and extracted metadata into, respectively,generic transformed additional source health data 118-1 information andgeneric transformed additional source metadata 118-2. Features of thesecond branch template loading 408C can include loading the generictransformed additional source health data 118-1 into a second branchadditional source generic data template and loading the generictransformed additional source metadata 118-2 into an additional sourcegeneric metadata template. In an embodiment, second branchsource-specific SP wrapping 408D can include wrapping the templateloaded form of the generic transformed additional source health data118-1 and template loaded form of the generic transformed additionalsource metadata 118-2 with an SP wrapping that complies with additionalsource sovereignty specification, e.g., additional source SPspecification data 118-3.

In an embodiment, third-party model source IE-DSW processing 410 caninclude, in response to receiving the third-party source model data fromthird-party model suppliers 108, a third branch information extracting410A, and associated therewith can be a third branch transforming 410B.Associated with the third branch transforming 410B can be third branchtemplate loading 410C, and associated therewith can be a third branch SPwrapping 410D. The third branch information extracting 410A can include,for example, extracting information content from third-party suppliermodel data from the third-party model suppliers 108 and the third branchtransforming 410B can include transforming the extracted modelinformation to generic transformed third-party supplier model data 120-1information and generic transformed third-party supplier metadata 120-2.The third branch template loading 410C can include loading the generictransformed third-party supplier model data 120-1 and generictransformed third-party supplier metadata 120-2 into a third branchtemplate. The third branch SP wrapping 410D can include third-partysupplier specific SP wrapping the third branch template loaded form ofthe generic transformed third-party supplier model data 120-1 andgeneric transformed third branch template loaded form of the generictransformed third-party supplier metadata 120-2 with an SP wrapping thatcomplies with third-party supplier sovereignty protective specification,e.g., 120-3.

Referring to FIG. 4, in an embodiment, features of the transform andconcept aligning 404 can include alignment of related conceptinformation and transformation of such information to an interoperablerepresentation. As will be understood by persons of ordinary skill uponreading this disclosure and practicing its various embodiments, thealignment includes specific alignments to knowledge representationschemata, and to analysis algorithm structures supported by the virtualdata warehouse and collaboration platform 128. For example in processesin accordance with the present disclosure, process flow, operationstherein, and other features that are in, or that support “transformationof such information to an interoperable representation” can include butare not limited to: formal ontologies, e.g., OWL and NIEM, interoperablerepresentation” can include but are not limited to: formal ontologies,e.g., OWL and NIEM. Tools that can be applied by the transform andconcept alignment logic 124 can include non-ontological knowledgerepresentations, e.g., an integrated phenotype reference model and otherknowledge representation schemata. Tools that can be applied by thetransform and concept alignment logic 124 include standardizedvocabularies, e.g., SNOMED, data dictionaries, AI tools such as neuralnets trained for phenotyping and other analyses by ML and deep learning,and data dictionaries. As also described in more detail in latersections of this disclosure, the above-listed example tools, applied byor through methods and systems in accordance with this disclosure, canprovide, among other features, dimensional conformity and alignment ofrelated concepts in a manner enabling efficient multi-participantcollaborative, multi-layer analyses of multi-sourced health relatedinformation.

The transform and concept aligning 404 can be described as including afirst branch transform and concept alignment processing 412, e.g., forreceiving, extracting information content and performing particularprocessing of EHR system-sourced data, including SP wrapping informationcontent in accordance with EHR system SP specifications, such as ePHIand other data from the EHR systems 104, a second branch transform andconcept alignment processing 414, e.g., for additional source data, suchas health-related information from the additional sources 106, and athird branch transform and concept alignment processing 416, e.g., forthird-party models 108.

As shown by the FIG. 4 example implementation, first branch transformand concept alignment processing 412 can include first branchconsolidating 412A, first branch conforming 412B, first branchdimensionalizing 412C, and first branch codification of the total arc ofEHR system-sourced data transformations 412D (labeled “Codify Trxfm hx”in block 412D on FIG. 4).

Second branch transform and concept alignment processing 414 can includesecond branch consolidating 414A, second branch conforming 414B, secondbranch dimensionalizing 414C, and second branch codification of thetotal arc of additional source data transformations 414D (labeled“Codify Trxfm hx” in block 414D on FIG. 4).

Third branch transform and concept alignment processing 416 can includethird branch consolidating 416A, third branch conforming 416B, thirdbranch dimensionalizing 416C, and third branch codification of the totalarc of third-party model source data transformations 416D (labeled“Codify Trxfm hx” in block 416D on FIG. 4).

FIG. 5 is a functional block diagram of an example of an implementation500 of a virtual data warehouse and collaboration platform 128 for theFIG. 1 system 100 and for various other systems and methods forartificial intelligence enhanced medical record exchange and commonplatform collaboration based medical and public health situationassessment, and health services resource and response management, inaccordance with one or more embodiments. For purposes of description,the implementation 500 of the virtual data warehouse and collaborationplatform 128 will be alternatively referenced as “VDW-CP 500.” As usedherein, “VDW-CP” is a coined, alternative form for reciting “virtualdata warehouse and collaboration platform,” having no intrinsic meaning.It will be understood that, as used in this disclosure, “VDW-CP” is anarbitrary coined letter string that serves only as a reduced lettercount representation of the word sequence “virtual data warehouse andcollaboration platform” and, as used herein, does not have, import orcarry any intrinsic meaning.

In an embodiment, VDW-CP 500 can store transformed ePHI information502-1 and transformed EHT metadata 502-2 within a first VDW-CPtransformed SP wrapper 504. The first VDW-CP transformed SP wrapper 504can include a first VDW-CP transformed SP provenance layer 504-1, afirst VDW-CP transformed SP persistent encryption layer 504-2, and afirst VDW-CP transformed SP rules of engagement layer 504-3. In anembodiment, the VDW-CP 500 can construct the first VDW-CP transformed SPwrapper 504 based at least in part on the EHR information SP wrapping302, or on EHR source SP specification data, e.g., EHR system SPspecification data 116-3 on which, as described above in reference toFIG. 3, the EHR information SP wrapping 302 may be based.

In an embodiment, the VDW-CP 500 can store transformed additional sourceinformation 506-1 and transformed additional source metadata 506-2,within a second VDW-CP transformed SP wrapper 508. The second VDW-CPtransformed SP wrapper 508 can include a second VDW-CP transformed SPprovenance layer 508-1, a second VDW-SP transformed SP persistentencryption layer 508-2, and a second VDW-CP transformed SP rules ofengagement layer 508-3. In an embodiment, the VDW-CP 500 can constructthe second VDW-CP transformed SP wrapper 508 based at least in part onadditional source information SP wrapping 304 or on additional source SPspecification information, received from third-party model suppliers108, on which additional source information SP wrapping 304 can bebased. In an embodiment, the VDW-CP 500 can store transformedthird-party source model information 510-1 and transformed third-partysource metadata 510-2 within a third VDW-CP transformed SP wrapper 512.The third VDW-CP transformed SP wrapper 512 can include a third VDW-CPtransformed SP provenance layer 512-1, a third VDW-CP transformed SPpersistent encryption layer 512-2, and a third VDW-CP transformed SPrules of engagement layer 512-3. In an embodiment, the VDW-CP 500 canconstruct the third VDW-CP transformed SP wrapper 512 based at least inpart on third-party supplier model information SP wrapping 306, orthird-party source SP specification data, e.g., third-party supplier SPspecification data 120-3 on which the third-party supplier modelinformation SP wrapping 306 can be based.

Referring to FIG. 5, the VDW-CP 500 can store hosted telecollaborationdata 514-1 and hosted telecollaboration metadata 514-2, within a VDW-CPtelecollaboration SP wrapper 516. The VDW-CP telecollaboration SPwrapper 516 can include a VDW-CP telecollaboration SP provenance layer516-1, a VDW-CP telecollaboration SP persistent encryption layer 516-2,and a VDW-CP telecollaboration SP rules of engagement layer 516-3. In anembodiment, the VDW-CP 500 can construct the VDW-CP telecollaboration SPwrapper 516 based at least in part on external sources' SP specificationdata that was received by and used by the FIG. 4 information extractingand data sovereignty wrapping 402 for performing the appropriate SPwrapping.

In an embodiment, the “based at least in part on,” can include, forexample, direct use of the external sources' SP specification data,e.g., for generating the EHR system SP specification data 116-3,additional source SP specification data used for generating additionalsource SP specification data 118-3, and third-party supplier SPspecification information for generating third-party supplier SPspecification data 120-3, or portions thereof. In an embodiment, “basedat least in part on” can include indirect use of the external sources'specification data, for example, using information regarding the EHRinformation SP wrapping 302, the additional source information SPwrapping 304, or the third-party supplier model information SP wrapping306, or any combination or sub-combination thereof. In an embodiment,such information regarding the EHR information SP wrapping 302,additional source information SP wrapping 304, or third-party suppliermodel information SP wrapping 306 can be provided to the computerizedtransforming and concept aligning 404, for example, via the virtual datawarehouse and collaboration platform 128.

In an embodiment, construction of the VDW-CP telecollaboration SPwrapper 516 can be further based at least in part on the SPspecification data provided by various among the external sources, e.g.,to the data curation 110. In one or more embodiments, provided caninclude, but are not limited to, consistency and reliability in formingthe VDW-CP telecollaboration SP wrapper 516 with a configuration thatcan maintain sovereignty protection, throughout the variousmulti-participant analyses supported on the virtual data warehouse andcollaboration platform 128.

FIG. 5 shows the virtual data warehouse and collaboration platform 128supporting a meta-meta-data 518, which can be information about themetadata. As an illustrative example of a meta-meta-data 518, assumethat metadata associated with a first EHR record includes a medicalconcept identified from the content of the first record and listed inthe derived concept market with a specified degree of certainty; assumefurther that metadata associated with a second EHR record includes amedical concept identified from the content of the second record andlisted in the derived concept market with its own degree of certainty.An example of meta-meta-data 518 can be information regarding the degreeof certainty that the two concepts from EHR first record and EHR secondrecord represent the same medical concept.

FIG. 5 also shows a derived concept market 520 and storage, e.g., on thevirtual data warehouse and collaboration platform 128, an indication ofa Patient O, of a Disease X, and an Anomaly as indications of commonconformed dimensions. Patient O, Disease X, and Anomaly are teachingexamples of common conformed dimensions that may be contained within thederived concept market 520. Lines are shown on FIG. 5, attaching eachconcept to each of the individual data marts 502-1, 506-1, 510-1, and514-1. One cluster 522 of the lines represents an example state of thebridge shown on FIG. 1 between the transformed component data and thecommon conformed dimensions within the derived concept market 520.Another cluster 524 of the lines represents an example state of thebridge on FIG. 1 between the transformed additional source data and thecommon conformed dimensions in the derived concept market 520. Anothercluster 526 represents an example state of the FIG. 1 bridge between thetransformed hosted telecollaboration data and the common conformeddimensions in the derived concept market 520, and another cluster 528represents an example state of the FIG. 1 bridge between the transformedthird party models and the common conformed dimensions in the derivedconcept market 520.

FIG. 6 shows by graphic overlay on FIG. 5 one example generalconfiguration of a multi-participant telecollaboration as can be hostedon the virtual data warehouse and collaboration platform 128 of FIG. 1of systems and methods for artificial intelligence enhanced medicalrecord exchange and common platform collaboration based medical andpublic health situation assessment, and health services resource andresponse management in accordance with one or more embodiments. Thegeneral configuration includes a visible plurality of participants 602,interconnected by communication links 604. The participants 602 can beindividuals, can be business entities, academic institutions, orgovernment agencies. The communication links 604 can represent extantcommunications, communication resources, agreements for periodiccommunication, agreements for “as needed” communication between multipleparticipants 602. The FIG. 6 quantity or population of graphical imageslabeled “602” is based in part on drafting considerations, and is notintended as any statement of preference or limitation on practicesaccording to disclosed embodiments.

FIG. 7 shows a logic schematic of a specific software development kit(SDK) 700 implementation of the system 100 SDK 132, configured toenable, through novel features and novel combinations of such featureswith features of system 100, multi-contributor maintenance coupled withevolution of a multi-tool suite of analysis apps. The multi-contributormaintenance and coupled evolution provides a robust multi-tool suite ofanalysis apps. The multi-tool suite of analysis apps can, in turn,provide AI enhanced multi-tool analysis resource for coupling to amulti-institutional knowledge database, for the FIG. 1 system andvarious other systems and methods for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

The FIG. 7 SDK 700 implementation includes natural language processing(NLP) and text analytics tools 702A; statistical analysis tools 702B;Graphical User Interface (GUI) and Data Visualization (Data Viz) tools702C; relation and collaboration tools 702D; geospatial tools 702E; AI,machine learning (ML), and deep learning (DL) modeling tools 702F;policy operationalization tools 702G; gaming scenario tools 702H; queryengine(s) 7021; project and task management tools 702J; import andexport tools 702K; and data integrity and security tools 702L. Theabove-listed example plurality of SDK tools will be collectivelyreferenced as “FIG. 7 SDK tool suite 700.” It will be understood thatthe SDK tool suite 700 is an example, not a limitation of what can bemany different SDK tool suites that may be used in practices accordingto disclosed embodiments, and the appended claims. Regarding aspects ofdifferences of the different SDK tool suites, examples includedifference with respect to the number of different analytics tools, anddifferent combinations of the tools, and respective configurations ofthe tools.

It will be understood that allocation and arrangement of hardware,software, and combination hardware-software resources in implementationsof the SDK tool suite 700 are not necessarily grouped, segmented, orpartitioned in accordance with above-listed individual analytic tools.Further, implementations of various of the analytics tools can includefunctionalities overlapping functionalities of other of the analyticstools. As an illustrative, non-limiting example, various implementationof the gaming scenario tools 702K can include functionalities of, or canbe constructed or evaluated, or both, using ML and other AI tools.

FIG. 8 shows a logic schematic of an example of a configuration 800 of acurated applications resource that can be provided, for example, by theapp market 134 of the FIG. 1 system 100. The configuration 800 showsexamples of third party and user contributed applications for the FIG. 1system and for various other systems and methods for AI enhanced medicalrecord exchange and common platform collaboration based medical andpublic health situation assessment, and health services resource andresponse management in accordance with one or more embodiments. Thegroupings of the applications into app market first applications regions802 and app market second applications regions 804 are for logistics offigure labeling, and are not intended to convey any grouping as tofunctionality, configuration, or features.

FIG. 9 shows a logic schematic of an example configuration 900 of theGUI 136 of the FIG. 1 system 100, with illustrative examples of widgetGUI regions 902-1, 902-2, . . . 902-R (collectively “GUI first widgetregions 902”), “R” being any integer and widget GUI regions 904-1,904-2, . . . , 904-S (collectively “GUI second widget regions 904”), “S”being any integer. The groupings of the widget regions into GUI firstwidget regions 902 and GUI second widget regions 904 are for logisticsof figure labeling, and are not intended to convey any grouping as tofunctionality, configuration, or features. Widgets associated with theGUI first widget regions 902 and GUI second widget regions 904 can befor system 100 and for processes and methods supported by same, or byother systems or system configurations according to this disclosure, forAI enhanced medical record exchange and common platform collaborationbased medical and public health situation assessment, and healthservices resource and response management in accordance with one or moreembodiments.

FIG. 10 shows a function block schematic with certain logic details ofan example adaptation of the FIG. 1 system, including the FIG. 3configuration of the combined staging database 114 in accordance withFIG. 2 and with the FIG. 3 implementation of the sovereignty protectivewrapping feature. FIG. 10 also shows the FIG. 4 flows of transferring ofdata into and out from the combined staging database. The FIG. 10adaptation can provide an environment for various systems and methodsfor AI enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management, in accordance with oneor more embodiments.

FIG. 11 shows a graphic overlay on FIG. 10 of FIG. 2 flow annotationsfor the data pipeline flow 202, concept and model pipeline flow 204, andactionable information and decision pipeline 206, representing theabove-described features as provided by FIG. 10 system adaptation.Features of the FIG. 11 system can include, without limitation,sovereignty protective extraction, via, for example, and informationextracting, sovereignty protective wrapping logic such as implemented bythe IE-DSW logic 112. The IE-DSW logic 112 provides for receiving an EHRdata, e.g., from one of the EHR system sources 104 and in response,wrapping, in an EHR system-specific sovereignty protective wrapper, agenericized form of a health-related information content of the EHRdata. Such features are provided, for example, by the IE-DSW logic 112functions, shown in FIG. 11 and described earlier in reference to FIG.4, of first branch information extracting 406A, first branchtransforming 406B, first branch loading 406C, and first branchsource-specific wrapping 406D. The FIG. 11 combined staging database 114provides a staging database, coupled to the information extracting,sovereignty protective wrapping logic, i.e., to the IE-DSW logic 112,and configured to store, in accordance with the EHR system-specificsovereignty protective wrapper, the genericized form of thehealth-related information content of the EHR data. The FIG. 11 systemalso includes the transform and concept alignment logic 124, coupled tothe combined staging database 114, and configured to perform atransforming of and aligning of the genericized form of thehealth-related information to a transformed interoperable health-relateddata. Various features of the features of the transforming and aligningare described above, and such features and additional features aredescribed in more detail in subsequent paragraphs, e.g., in reference toFIG. 18 and, regarding a further configuration, in reference to FIG. 21.In an embodiment, the FIG. 11 system also provides collaborationplatform 128, which is coupled to the transform and concept alignmentlogic 124, and is configured to perform a hosting of a telecollaborativeanalysis of the transformed interoperable health-related data.Telecollaborative analysis can be provided by one or more of theparticipants, e.g., one or more of the participants 602 visible in FIG.6. Features of the collaboration platform 128 can also include, providedfor example, by the VDW-CP telecollaboration SP wrapper 516 described indetail in reference to FIG. 5, a wrapping, in a telecollaborationparticipant specific sovereignty protective wrapper, of atelecollaboration data associated with a telecollaboration participant.The collaboration platform 128 can also provide, as described inreference to FIG. 5, a maintaining during the telecollaborative analysisof the transformed interoperable health-related data, a sovereignty ofthe transformed interoperable health-related data in accordance with theEHR system-specific sovereignty protective wrapper, and a sovereignty ofthe telecollaboration data associated with the telecollaborationparticipant in accordance with the telecollaboration participantspecific sovereignty protective wrapper.

FIGS. 12A and 12B are a two-sheet arrangement of a functional block andsupported process diagram of another example system in accordance withone or more embodiments for AI enhanced medical record exchange andcommon platform collaboration based medical and public health situationassessment, and health services resource and response management inaccordance with one or more embodiments.

FIG. 12A and FIG. 12B, viewed together, are a graphical representationof logic operations and processes for which the transform and conceptalignment logic 124 can be configured. A further of view of theseprocesses is shown on FIG. 13A. Referring to FIG. 12A, in an embodiment,features can include an AI-computed interoperability mapping 1202, suchas represented in table form in the figure It will be understood thatthe computed cells of the table representing the AI computedinteroperability mapping produces probabilistic, not binary, dimensionalconformity and alignment of related concepts, and therefore if the tablewere larger the cells could be filled by a shading having respectivecell-specific degree of grey. In an embodiment, the AI-computedinteroperability mapping 1202 can provide an AI-leveragedinteroperability path 1204. In an embodiment, a validation, such asmanual validation may be utilized, as represented by persons 1206 on theAI-leveraged interoperability path 1204. Manual validation may not beessential, but can be used, e.g., to have the “human-in-the loop.”

In an embodiment, manual mapping of interoperability, such asrepresented on the figure by individuals 1208, can generate a manualinteroperability map 1210, such as represented on the figure by anothertable. The manual interoperability map 1210 can provide a manuallymapped interoperability path 1212. In accordance with one or moreembodiments, cross-support can be provided, by exchanging 1214 ofinformation between the AI-leveraged interoperability path 1204 and themanually mapped interoperability path 1212.

Referring to FIG. 12B, the data plot 1216 represents secondary analyticsthat, together with the AI neural network 1218, can support theintegrated phenotype reference model 1220, and can directly provideoutput to the collaborative network 1222.

FIGS. 12A and 12B show example of features of analytics and artificialintelligence. Example features of analytics can include, but are notlimited to, traditional statistical analysis, and example aspects of AIcan include machine learning techniques in which executable code candynamically alter behavior based on information from monitoring andsensing resources. FIGS. 12A and 12B fit into the 124 column of FIG.13A. FIGS. 12A and 12B are a pictorial representation of 124, and showin much more detail how the processes listed in 124 are accomplished.

FIGS. 13A and 13B are a two-sheet arrangement of functional block andassociated process diagram showing aspects of an example system ingeneral accordance with the FIG. 10 system for medical and public healthservice resource and response management via AI enhanced medical recordexchange feeding concept generation and dynamic updating ofmulti-institutional knowledge database coupled to AI enhanced multi-toolanalysis resources in accordance with one or more embodiments.

FIGS. 12A-B show examples of features of analytics and artificialintelligence. Example features of analytics can include, but are notlimited to, traditional statistical analysis, and example aspects of AIcan include machine learning techniques in which executable code candynamically alter behavior based on information from monitoring andsensing resources. FIGS. 12A-B fit into the 124 column of 13A. FIGS. 12Aand B are a pictorial representation of 124, and show in much moredetail how the written processes listed in 124 are accomplished.

Below is element 1224 of FIG. 12B enlarged to show detail and improvereadability of the text.

PHEN100 FK503 37% 84% FK301 41% 70% FK402 13% 53% FK202  9% 63% FK20141% 98% FK101 14% 79% FK203 31% 92% FK303 33% 53% FK401 21% 60% PHEN200FK501  3% 93% FK103 37% 64% FK402 39% 69% FK502 48% 55% FK302 13% 52%FK503 20% 53% FK101 23% 59% FK303 33% 70% FK102 18% 54% FACT FK101 19%FK301 85% FK401 98% FK402 50% FK502 33% FK403  8% FK202 70% FK103 11%FK101 13% FK102 77% FK101  3% FK501 22% FK103  0% FK401 59% FK203  8%FK401 56% FK303 52% FK102 77% FK503 25% FK503  1% DIM100 PK101 34295PK102 22701 PK103 72076 DIM200 PK201 11651 PK202 26049 PK203 98725DIM300 PK301 73314 PK302 63976 PK303 72909 DIM400 PK401 44249 PK40257004 PK403 53772 DIM500 PK501 89727 PK502 10925 PK503 93379

Referring to FIG. 13A, each of the EHR data source 1302, additionalparties data source 1304, and third party model data source 1306 can bepiped through all the processes of the transform and concept alignmentlogic 124, and can emerge at jump points (c), (d), and (e), ready forthe data warehouse 126. For purposes of description, the processes ofthe transform and concept alignment logic 124, which, in an embodiment,comprise consolidate, conform, dimensionalize, and codify may becollectively referred as “analytics and AI engine.” In an embodiment,the emergence at jump points (c), (d), and (e), described above, can beconsidered as entry points, in a logic sense, into the largemeta-database shown as the derived concept market 520 on FIG. 5, and asthe derived market concept 1902 on FIG. 19.

FIG. 14 is a logic diagram of flows of certain features and aspectsshown in FIG. 13A. In an embodiment, flows include data curation 110.Features of the data curation 110 can include filtering of data receivedfrom external sources, such as but not limited to ePHI and other healthinformation received from a plurality of independent, differentlystructured instances of EHR systems 104, additional health relatedinformation from additional sources 106, and analysis model informationfrom a plurality of third-party model suppliers 108. In an embodiment,the filters can be configured in accordance with trusted third-partybrokered data use agreements (DUAs) and other contracts. In one orembodiments, such filters can be applied to each contributed dataset.Also enforcement of the filters can persist through many layers of manydifferent transformations, different users, and different collaborativegroups of users. Such application and persistence can help ensure datasovereignty throughout the system and the methods supported by thesystem. The data sovereignty can be enforced, and maintained throughoutIE-DSW logic 112 extraction, genericizing, e.g., transformation togeneric form, loading of the transformed generic form information andmetadata, e.g., into templates, and wrapping as per source-specific SPspecifications. Further features can include adaptability of thecombined staging database 114 to store, and maintain data sovereignty ofthe multiple sources' metadata. This feature has significant benefits,as metadata can grow considerably during each transformation and asdifferently provenanced data are integrated.

Referring to FIG. 14, as described above, transform and conceptalignment logic 124 can include a published API 1402 that can supporttransform and concept aligning with resources that include analysestools 1404 achieving dimensional conformity and alignment of relatedconcepts, from: formal ontologies (e.g., OWL), reference models (e.g.,NIEM). Standardized vocabularies (e.g., SNOMED), clustering 1406, forexample, unsupervised DL trained AI clustering, other neural networks1408 providing ML/DL trained AI phenotyping, data dictionaries, bothsupervised and unsupervised techniques and data dictionaries. In anembodiment, the provided phenotyping retrieves, compares, and updatesconcept relationships in the Integrated Phenotype Reference Model 1410.Such alignment of related concepts facilitates collaboration on thecollaboration platform 128, which can foster, for example, efficientmulti-participant collaborative, multi-layer analyses of health-relatedinformation from a large of independent EHR systems and other sources.

FIG. 15 shows a master diagram of a process 1500, in an implementationof a method of artificial intelligence (AI) enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments. The FIG. 15master diagram is arranged for convenience of description to comprisefour logic flow portions. The arrangement into four logic flow portionsis for convenience of description, including rendering variousprocess-internal flows as inter-portion flows, thereby facilitatingdescription of certain features. The arrangement into four logicportions is not intended as any limitation, or any indication ofpreference as to physical distribution or grouping of hardware, orallocation of functionality to hardware. The arrangement into logicportions is also not intended as a statement that arrangement into logicportions is necessary for description.

In an embodiment, the process 1500 can include a receiving and IE-DSWprocessing 1502, a combined staging database processing 1504, atransforming and concept alignment processing 1506, and a transformed,interoperable processing 1508. The receiving and IE-DSW processing 1502can be an example implementation of the data curation 110 processesdescribed above, e.g., in reference to FIG. 1, as well as an exampleimplementation of the IE-DSW processing 402 also described above, e.g.,in reference to FIG. 4, and as visible by the flow arrows passingthrough the in FIGS. 10, 11, 13A, and 14. The combined staging databaseprocessing 1504 can be an example implementation of the SP wrappedstoring processes described above as performed by the combined stagingdatabase 114. The transforming and concept alignment processing 1506 canbe an example implementation of the transform and concept alignmentlogic 124 described above, e.g., in reference to FIGS. 12A and 12B. Thetransformed, interoperable processing 1508 can be an exampleimplementation of the virtual data warehouse and collaboration platform128 described above, e.g., in reference to FIG. 13B.

Visible on FIG. 15, a dotted line box encloses the graphic block for theIE-DSW processing 1502, and within the dotted line are references toFIG. 16 and FIG. 20. The references indicate FIG. 16 and FIG. 20, whichare described in detail later, showing respective flow diagrams ofexample implementations of the receiving and IE-DSW processing 1502. Inlike manner, on FIG. 15 are three additional respective dotted lineboxes, which surround, respectively, the combined staging databaseprocessing 1504 block, the transforming and concept alignment processing1506 block, and the transformed, interoperable processing 1508 block.Within the dotted line box surrounding the combined staging databaseprocessing 1504 is a reference to FIG. 17, and within the dotted linebox surrounding the transformed, interoperable processing 1508 is areference to FIG. 19. These references indicate that FIG. 17 and FIG.19, each described in more detail later in this disclosure, show,respectively, a detailed flow diagram of an example implementation ofthe combined staging database processing 1504, and a detailed flowdiagram of an example implementation of the transformed, interoperableprocessing 1508. Within the dotted line box surrounding the transformingand concept alignment processing 1506 are references to FIG. 18 and FIG.21, both of which are described in more detail later in this disclosure.These references that FIG. 18 and FIG. 21 show detailed flow diagramsof, respectively, a first example implementation and a second exampleimplementation of the transforming and concept alignment processing1506.

FIG. 15 shows for the receiving and IE-DSW processing 1502 a flow input“DI” and flow outputs “A,” “B,” “C,” “D,” and “E,” and shows for thecombined staging database processing 1504 flow inputs A, B, and C, andflow outputs “F,” “G,” and “H.” FIG. 15 also shows for the transformingand concept alignment processing 1506 flow inputs F, G, D, and “P,” andflow outputs “I,” “J,” “K,” “L,” “M,” “N,” and “O,” and shows for thetransformed, interoperable processing 1508 flow inputs H, I, J, K, L, M,N, and O, and flow output P.

FIG. 16 and FIG. 20 show the same flow inputs and outputs as FIG. 15shows for the receiving and IE-DSW processing 1502 that for which FIG.16 and FIG. 20 show implementations. FIGS. 17 and 19 show, respectively,the same flow inputs and outputs as FIG. 15 shows for the combinedstaging database processing 1504, and the transformed, interoperableprocessing 1508 that the FIGS. 17 and 19 flows respectively implement.FIG. 18 and FIG. 21 show the same flow inputs and outputs as FIG. 15shows for the transforming and concept alignment processing 1506, forwhich FIG. 18 and FIG. 21 show implementations.

Interconnecting, in accordance with the interconnects visible on FIG.15, the respective flow inputs and outputs of FIGS. 16, 17, 18, and 19will form an integrated flow schematic of an example detailedimplementation of the process 1500. Substituting the FIG. 20implementation for the FIG. 16 implementation of the receiving andIE-DSW processing 1502, using interconnects visible on FIG. 15, therespective flow inputs and outputs of FIGS. 20, 17, 18, and 19, willform an integrated schematic of another example detailed implementationof the process 1500. In like manner, substituting the FIG. 21implementation for the FIG. 18 implementation of the transforming andconcept alignment processing 1506, and interconnecting, in accordancewith the interconnects visible on FIG. 15, the respective flow inputsand outputs of FIGS. 16, 17, 21, and 19, will form a unitary flowschematic showing another example detailed implementation of the process1500. In addition, substituting the FIG. 20 for the FIG. 16implementation of the receiving and IE-DSW processing 1502, incombination with substituting the FIG. 21 implementation for the FIG. 18implementation of the transforming and concept alignment processing1506, and interconnecting the figures as described above, forms anintegrated flow schematic of yet another example detailed implementationof the process 1500.

An embodiment in accordance with the FIG. 15 process 1500 will now bedescribed, assuming the FIG. 16 implementation of the receiving andIE-DSW processing 1502, the FIG. 17 implementation of the combinedstaging database processing 1504, the FIG. 18 implementation of thetransforming and concept alignment processing 1506, and the FIG. 19implementation of the transformed, interoperable processing 1508. Forpurposes of description, an example of the process 1500 in accordancewith this example implementation, will be referenced as the “firstimplementation process 1500.” An example instance of the firstimplementation process 1500 will be described assuming the system 100 asthe environment, and assuming that the external source is a particularone of the EHR systems 104, there is no DUA in place between the entitymanaging the system 100 and the particular one of the EHR systems 104,that the DUA includes the SP specifications for performing the SPwrapping, and that third-party model supplier 108 models are alreadyloaded onto the virtual data warehouse and collaboration platform 128.

Descriptions of various features of and of example operations accordingto the process 1500 include references to FIG. 1 and to other appendedfigures. Such references are to further assist in understanding of theprocess 1500, through illustration by examples. Such references are notintended as a statement that practices in accordance with disclosedembodiments are limited to system 100 or to above disclosedimplementations of the system 100 logic blocks.

Referring to FIG. 16, in an embodiment, operations in the firstimplementation process 1500 can include, e.g., responsive to receivingan EHR data from a particular one of the EHR systems 104, proceeding tothe process flow 1600, and in the process flow 1600 determining 1602whether there is a DUA between the entity managing the system 100 andthe particular one of the EHR systems 104. As stated above, it isassumed for this example that no DUA is in place. Accordingly, thedetermining 1602 returns a negative result and, in response, the processflow 1600 can proceed to computerized DUA formation 1604. Thecomputerized DUA formation 1604 can include a DUA generation resource.In an embodiment, the DUA can determine, or can embody the SPspecifications for subsequent wrapping, in later operations of theprocess flow 1600. In an embodiment, the DUA can encode an identifierfor the SP specifications, and the process flow 1600 can includeoperations for storing the SP specifications in a manner retrievable,for example, using the encoded identifier. In one or more embodiments,SP specification can be communicated pursuant to or associated withcreation of the DUA, between the source of the dataset (e.g., EHR system104), and an entity managing the process 1500.

In an embodiment, on completion of the computerized DUA formation 1604the process flow 1600 can proceed, e.g., via a return path 1606, todetermining 1608 the type of the received external sourced data. Reasonsfor determining 1608 the type of the received health-related data caninclude configuring the subsequent step, which can be the preprocessing1610. As will be described in more detail in reference to the FIG. 20alternative configuration “type[s],” determining 1608 can includestreaming health data, bulk-type load health data, real-time EHR systemuser entered data, and other examples. Assuming the received EHR data isof a type recognized or acceptable to the determining 1608, the processflow 1600 can proceed to preprocessing 1610 the received data into acommon format configured for feeding the first of subsequent steps. Inone or more embodiments, for particular data transfers, operations at1608 and 1610 may require performance only once, e.g., at the beginningof the data transfer.

From the preprocessing 1610 the process flow 1600 flow can then proceedto extracting 1612 which the information content, e.g., ePHI informationcontent and EHR metadata information from EHR data. The process flow1600 can then proceed to transforming 1614 the extracted information andmetadata, e.g., ePHI information and EHR metadata information, to ageneric transformed PHI information and generic transformed EHRmetadata, and then to loading 1616 the generic transformed PHIinformation and generic transformed EHR metadata into the preliminarystaging resource 1618. In one or more embodiments, the preliminarystaging resource 1618 can function as a buffer memory, for holdingtransformed generic form health information and transformed, genericform metadata prior to wrapping, as described in more detail in thefollowing paragraphs.

The extracting 1612, transforming 1614, and loading 1616 can be exampleimplementations of operations in the computerized information extractingand data sovereignty wrapping 402 described above in reference to FIG.4. For example, the extracting 1612 and transforming 1614 can beimplementations, respectively, of the first branch informationextracting 406A and first branch transforming 406B, and the loading 1616can be an implementations of the first branch loading 406C.

With continuing reference to FIG. 16, over intervals following storingthe generic transformed PHI information and EHR metadata in thepreliminary staging resource 1618, the process flow 1600 can proceed todetecting 1620 structure of the generic transformed PHI information andgeneric transformed EHR metadata. For example, after the detecting 1620,the process flow 1600 can proceed to correcting 1622 for data type, andmanaging 1624 data corruptions. In an embodiment, over time intervalsthat may be concurrent with, or separate from time intervalscorresponding to the detecting 1629, correcting 1622, and managing 1624,operations in the process flow 1600 can include an encryption and keymanaging process 1626 configuring a wrapping 1628 that, when applied,can include encrypting and wrapping the generic form health-related dataand generic form metadata as received, after any correcting 1622 fordata type, and any managing 1624 of data corruptions. In an embodiment,the configuring operations by the encryption and key managing process1626 can include, for example, loading a process, e.g.,computer-executable instructions into a computer resource allocated, ordedicated, or assigned to perform the wrap process. The process, invarious embodiments, can be configure in accordance with the DUA, i.e.,to meet the SP specifications defined by the DUA. The configuring caninclude defining an SP wrapper for the external sources information andmetadate, for example, assuming an EHR system 104 source, an SPspecification for an EHR information SP wrapping such as the EHRinformation SP wrapping 302 described above.

Referring to FIG. 15 and FIG. 16, in an embodiment, information for useby, or for controlling aspects of the encryption and key managingprocess 1626 can be exchanged, via flow input-output point D, betweenthe key managing process 1626 and a database that can be internal to thetransform, concept alignment processing 1506, which is described in moredetail later in this disclosure.

In an embodiment, operations in the process flow 1600 can include, overone or more time intervals subsequent to above-described configuringoperations by the encryption and key managing, feeding output of thewrapping 1628 to the combined staging database processing 1504, via flowoutput point of the process flow 1600 and into flow input point A of theprocessing 1504. The combined staging database processing 1504 can thenstore wrapped, generic transformed versions of EHR system 104 sourcedhealth-related information and metadata.

In an embodiment, operations in the process flow 1600 can includecommunication to the combined staging database processing 1504 ofinformation regarding the wrapping and encryption applied by wrapping1628. The communication can be, for example, from flow output point B toflow input point B of the combined staging database processing 1504.

In an embodiment, the process flow 1600 can also include outputtinginformation regarding any one or more among detecting 1620 structure ofthe generic transformed PHI information and generic transformed EHRmetadata, correcting 1622 for data type, and managing 1624 datacorruption. As visible in FIG. 16, in an implementation, the processflow 1600 can output such information, for example from process flow1600 flow output point C to flow input point C of the combined stagingdatabase processing 1504.

In an embodiment, the process flow 1600 can include a policy-basedschedules and triggers process and, in an example implementation, saidprocess can feed information, from example, from flow output point E torepresentative flow input point E of the external sources 1501.

Referring to FIGS. 1, 4, 15, and 16, it will be understood thatoperations in the extracting 1612, transforming 1614, and loading 1616can be performed, for example, by the IE-DSW logic 11. Referring to thesame figures, together with FIG. 17, the combined staging databaseprocessing 1504 can implement the combined staging database 114described above.

FIG. 17 shows a process flow diagram of an example implementation of thecombined staging database processing 1504 in the FIG. 15 process 1500.The implementation can be for methods for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

Referring to FIG. 17, the implementation logic can include a data lake1702 and, in an embodiment, the data lake 1702 can be provided withrole-, attribute-, and dynamic policy-based access controls. An exampleof role-based and attribute-based access controls can includequalifications or permissions assigned to participants, e.g.,participants 602, to access data with particular attributes as specifiedin an appropriate DUA. An example of dynamic policy-based accesscontrols can include changing the assigned permissions to access datawith particular attributes, depending on the situational context. Proofof such qualifications or permissions can be communicated, as anexample, by a subscription name, password sequence, or comparableverification protocol. In an embodiment, operations of the data lake1702 can include, e.g., via flow pads A and B on FIGS. 16 and 17,communication of suitably wrapped EHR information and EHR metadata,respectively. Flow output pads of the FIG. 17 resource include an outputpad F and output pad G.

FIG. 18 shows a flow diagram of an example process flow 1800 that canimplement the transform and concept alignment processing 1506 in theFIG. 15 process 1500. The example process flow 1800 can be further to AIenhanced medical record exchange and common platform collaboration basedmedical and public health situation assessment, and health servicesresource and response management in accordance with one or moreembodiments. Description of operations according to the process flow1800 will use certain assumptions. One is that EHR system 104 sourceddataset described above has been received by the FIG. 16 process flow1600, i.e., information content and metadata have been extracted,genericized, and stored in an SP wrapping in the combined stagingdatabase processing 1504, e.g., as per the FIG. 17 implementation. Thereceiving, as visible in FIG. 18, can be via process flow 1800 flowreception points F and G, respectively, connected to FIG. 17 flow outputpoints F and G.

In overview, operations of the process flow 1800 include interoperableprocessing 1802, for transforming into one or more alternativecollaboration platform 128 supported knowledge presentation schemaconcepts represented by the genericized information content of, forexample, the EHR system 104 sourced dataset and metadata store in theFIG. 17 data lake 1702 and metadata storage 1704.

Operations according to process flow 1800 will be described in referenceto the example EHR dataset. However, in one or more embodiments, and invarious applications of such embodiments concept information carried orembodied in the external source data, e.g., EHR system 104 sourced data,may span multiple datasets, combinations of datasets and results ofprocessing datasets. Description of example operations of theinteroperable processing 1802 will therefore assume that priorprocessing has accumulated a usable content of databases that feed theinteroperable processing 1802. For example, it will be assumed thatprior processing, or a preloading, or operations in particularlyconfigured start-up process, or combinations thereof, have loaded theprocess flow 1800 first database 1808, holding deep learning, machinelearning data, and loaded the process flow 1800 second database 1810,holding integrated phenotype reference model information, and theprocess flow 1800 third database 1812, holding text annotation,indexing, windowing, and accrued corpus characteristics data. Likewise,it will be assumed that prior processing, or a preloading, or operationsin particularly configured start-up process, or combinations thereof,have loaded the process flow 1800 fourth database 1814, holding userdata, user input and behavior patterns, as well as social networkperformance and characteristics data. It will also be assumed that priorprocessing, or a preloading, or operations in particularly configuredstart-up process, or combinations thereof, have loaded the process flow1800 database 1816, holding data dictionaries and interoperability mapsavailable for interactive updating by the interoperability processing1802.

It will be understood that “loaded,” in this context, can encompass aloading of the identified databases, and of other of the process flow1800 databases as will be described, that is sufficient such thatsuccessive operations, based on successively obtained new datasets,e.g., new EHR system 104 sourced datasets, will reliably produce aconvergence of system or process state to a stable steady state.

In an embodiment, various operations in the process flow 1800 can beconfigured to receive, in addition to the wrapped, genericized healthrelated information and associated genericized metadata, run-time accessto reference terminology, ontology and encoding data from a resource ofreference terminology, ontology and encoding databases, and one or moreinformation exchange standardized model references. Regarding thereference terminology, ontology and encoding databases, in an embodimentthese can include, for example, as visible in FIG. 18, a first referenceterminology, ontology and encoding database 1804-1, a second referenceterminology, ontology and encoding database 1804-2, . . . , and a Q^(th)reference terminology, ontology and encoding database 1804-Q(collectively “reference terminology, ontology and encoding databases1804”). Q can be any integer, including integer one. Regarding theinformation exchange standardized model references, an exampleconfiguration, also visible in FIG. 18, can include information exchangestandardized model reference 1806.

Referring to FIG. 18, it will be understood the representation of thereference terminology, ontology and encoding databases 1804 by separateblocks is a logical representation and is not intended as any limitationas to physical arrangement or separation of respective storage.Implementation of the reference terminology, ontology and encodingdatabases 1804 can include, for example, storage of multiple referenceterminology, ontology and encoding databases 1804 in common, sharedstorage space of a common, shared storage resource. Implementation ofone or more of the reference terminology, ontology and encodingdatabases 1804 can also include remote storage of, or subscriptionaccess to one or more of the reference terminology, ontology andencoding databases 1804.

In an embodiment, operations in the process flow 1800 can includereceiving and applying interoperability processing 1802 to wrapped,genericized medical and public health related information, and wrapped,genericized metadata, e.g., via accesses of the data lake 1702. Suchaccesses can be initiated, for example, by the process flow 1800, e.g.,associated with a user or collaboration of users of the collaborationplatform 128 using applications in the app market 134. As visible inFIG. 15, instances of interoperability processing 1802 can receive, bypushes to the process 1802 or by accesses performed by the process 1802,reference terminology, ontology and encoding data from the up to Qreference terminology, ontology and encoding databases 1804-1, 1804-2, .. . , 1804-Q, together with information exchange standardized model datafrom the information exchange standardized model reference 1806; deeplearning, machine learning, and other models data, from the process flow1800 first database 1808; phenotype reference model information from theprocess flow 1800 second database 1810; text annotation, indexing,windowing, and accruing corpus characteristics data from the processflow 1800 third database 1812; user data, input and behavior, socialnetwork performance and characteristics data from the process flow 1800fourth database 1814; and data dictionary(ies) and interoperabilitymap(s) data from the data dictionary(ies) and interoperability map(s)database 1816. Results of the interoperability processing 1802 can beloaded as common conformed dimensions, which could have either fuzzy orcrisp degrees of certainty, into the process flow 1800 fifth database1818.

Referring to FIGS. 1, 15, 18, and 19, it is seen that the commonconformed fuzzy and crisp dimensions data can implement the hosting, onthe virtual database and collaborative platform 128, of transformed andEHR sourced health related information, for collaborative analyses bythe FIG. 15 process 1500, a transformed, interoperable processing 1508.

Referring to FIG. 18, operations in the process flow 1800 can include,in addition to the above-described interoperability processing 1802, aprocess flow 1800 artificial intelligence data analytics processing1820, applied to transformed generic EHR data from the FIG. 17 data lake1702 and metadata storage 1704, also using reference terminology,ontology and encoding data from the up to Q reference terminology,ontology and encoding databases 1804-1, 1804-2, . . . , 1804-Q, togetherwith information exchange standardized model data from the informationexchange standardized model reference 1806, and input of integratedphenotype reference model information from the process flow 1800 seconddatabase 1810 and text annotation, indexing, windowing, and accruingcorpus characteristics data from the process flow 1800 third database1812. Results of the process flow 1800 artificial intelligence dataanalytics processing 1820 can be loaded, as updates or supplements todeep learning, machine learning, and other model data in the processflow 1800 first database 1808.

Operations in the process flow 1800 can also include, in addition to theabove-described interoperability processing 1802 and process flow 1800artificial intelligence data analytics processing 1820, a process flow1800 phenotype processing 1822, applied to transformed generic EHR datafrom the FIG. 17 data lake 1702 and metadata storage 1704, also usingreference terminology, ontology and encoding data from the up to Qreference terminology, ontology and encoding databases 1804-1, 1804-2, .. . , 1804-Q, together with information exchange standardized model datafrom the information exchange standardized model reference 1806, andtext annotation, indexing, windowing, and accruing corpuscharacteristics data from the process flow 1800 third database 1812.Results of the process flow 1800 phenotype processing 1822 can beloaded, as updates or supplements integrated phenotype reference modeldata in the process flow 1800 second database 1810.

Operations in the process flow 1800 can include, in addition to theabove-described interoperability processing 1802, process flow 1800artificial intelligence data analytics processing 1820, and process flow1800 phenotype processing 1822, a natural language processing 1824, alsoapplied to transformed generic EHR data from the FIG. 17 data lake 1702and metadata storage 1704, also using reference terminology, ontologyand encoding data from the up to Q reference terminology, ontology andencoding databases 1804-1, 1804-2, . . . , 1804-Q, and the informationexchange standardized model data from the information exchangestandardized model reference 1806. Results of the process flow 1800natural language processing 1824 can be loaded, as updates orsupplements to text annotation, indexing, windowing, and accruing corpuscharacteristics data in the process flow 1800 third database 1812.

In an embodiment, the process flow 1800 fifth database 1818 content ofcommon conformed fuzzy and crisp dimensions data, as updated by theinteroperability processing 1802, the process flow 1800 first database1808 content of deep learning, machine learning, and other model data,as updated by the process flow 1800 artificial intelligence dataanalytics processing 1820; the process flow 1800 second database 1810content of integrated phenotype reference model data as updated by theprocess flow 1800 phenotype processing 1822, and the process flow 1800third database 1812 content of text annotation, indexing, windowing, andaccruing corpus characteristics data as updated by the process flow 1800natural language processing 1824 can feed any one, or any combination orsub combination among the following example configuration of processflow 1800 processes: information retrieval and information pushprocessing 1826; clinical decision support and workflow supportprocessing 1828; pattern and anomaly detection processing 1830;spatiotemporal predictive models processing 1832; data visualization anddata manipulation processing 1834; and user experience and collaborationtools processing 1836.

In an embodiment, the process flow 1800 can also include a coderepository and a data transformations archive 1838.

FIG. 19 illustrates a functional block schematic of a virtual datawarehouse and collaboration network 1900, hosting an interoperable dataresource, showing an example implementation of the FIG. 15 virtual datawarehouse and collaboration platform and interoperable data resource,for methods for AI enhanced medical record exchange and common platformcollaboration based medical and public health situation assessment, andhealth services resource and response management in accordance with oneor more embodiments.

FIG. 20 shows a process flow diagram of an example of a process flow2000 of operations in the FIG. 16 process flow 1600, comprising aspecific implementation of the determining 1608 of data type and formatand a corresponding specific implementation of the converting bypreprocessing 1610 of received data type and format to a common format.In an example instance, operations of the process flow 2000 can includea determining 2002 of whether the EHR data is streaming data. Assumingthe determining 2002 produces a positive result, the process flow 2000can proceed to continuous data processing 2004, which can feedappropriately formatted continuous data to the extracting 1612, forprocessing as described in reference to FIG. 16.

In an embodiment, assuming the determining 2002 produces a negativeresult, the process flow 2000 can proceed sequentially, to determining2006 whether the received EHR data is a user input, e.g., in real timeto an EHR system standard GUI or other interface, and if the answer is“yes,” can proceed to forms processing 2008. In such an embodiment, ifthe determining at 2006 obtains a negative result, the process flow 2000can proceed to determining 2010 if the received EHR data is a scrapeand, if “yes,” can proceed to crawler processing 2012 and then toextracting 1612, for processing as described in reference to FIG. 16. Ifthe result of the determining 2010 is negative, the process flow 2000can proceed to determining 2014 whether the EHR data is part of, e.g., abeginning of a bulk load and, if the answer is “yes,” can proceed tosecure upload processing 2016 and then, as described above, toprocessing as described in reference to FIG. 16. In the exampleconfiguration visible in Fig. if the result of the determining 2014 isnegative, the process flow 2000 can proceed to determining 2018 whetherthe EHR data is a specified connection, i.e., is in a form acceptable tothe process, and, if the answer is “yes,” can proceed to sourceprocessing 2020, and then proceed to extracting 1612 and furtheroperations as described in reference to FIG. 16.

In an alternative embodiment, two or more of the determining steps canbe performed in parallel or substantially in parallel, and thecombination of operations can be collectively referenced as “EHR datatype determination.”

FIG. 21 shows a process flow diagram of an example alternative orfurther implementation of the transform and concept alignment processingin the FIG. 15 process for methods for AI enhanced medical recordexchange and common platform collaboration based medical and publichealth situation assessment, and health services resource and responsemanagement in accordance with one or more embodiments.

The alternative includes Reference Medical terminology, ontology andcoding (T, O, & C) 2102-1, Reference Laboratory T, O, & C 2102-2;Reference Medication T, O, & C 2102-3, Reference Social Determinants ofHealth T, O, & C 2102-4; Additional Reference T, O, & C 2102-5; andNational Information Exchange Model Reference 2102-6.

Computer System

FIG. 22 illustrates in simplified schematic form a computer system 2200,on which aspects of the present disclosure can be practiced. Thecomputer system 2200 can include a hardware processor 2202communicatively coupled to an instruction memory 2204 and to a datamemory 2206 by a bus 2208. The instruction memory 2204 can be configuredto store, on at least a non-transitory computer readable medium asdescribed in greater detail below, executable program code 2210. Thehardware processor 2202 may include multiple hardware processors and/ormultiple processor cores. The hardware processor 2202 may includecooperation with hardware processors from different devices. Thecomputer system 2200 may execute one or more basic instructions includedin the executable program code 2210. The computer system 2200 caninclude a network interface 2212 communicatively connected to the bus2208, for interfacing to a wide area network (WAN), e.g., the Internet2214. Also communicatively connected to the bus 2208 can be a GUI 2216.The computer system 2200 may also include a mass storage 2218, which canbe accessible to the hardware processor 2202 via the bus 2208.

Relationship Between Hardware Processor and Executable Program Code

The relationship between the executable program code 2210 and thehardware processor 2202 is structural; the executable program code 2210is provided to the hardware processor 2202 by imparting various voltagesat certain times across certain electrical connections, in accordancewith binary values in the executable program code 2210, to cause thehardware processor to perform some action, as now explained in moredetail.

A hardware processor 2202 may be thought of as a complex electricalcircuit that is configured to perform a predefined set of basicoperations in response to receiving a corresponding basic instructionselected from a predefined native instruction set of codes.

The predefined native instruction set of codes is specific to thehardware processor; the design of the processor defines the collectionof basic instructions to which the processor will respond, and thiscollection forms the predefined native instruction set of codes.

A basic instruction may be represented numerically as a series of binaryvalues, in which case it may be referred to as a machine code. Theseries of binary values may be represented electrically, as inputs tothe hardware processor, via electrical connections, using voltages thatrepresent either a binary zero or a binary one. The hardware processorinterprets the voltages as binary values.

Executable program code may therefore be understood to be a set ofmachine codes selected from the predefined native instruction set ofcodes. A given set of machine codes may be understood, generally, toconstitute a module. A set of one or more modules may be understood toconstitute an application program or “app.” An app may interact with thehardware processor directly or indirectly via an operating system. Anapp may be part of an operating system.

FIG. 23 shows a data preparation system 100A illustrating a first dataprovider 110A configured to provide a data information file 111A; amulti-source health data integration logic 120A configured to receive110P said data information file 111A from the first data provider 110A.The multi-source health data integration logic 120A containing: aninformation extractor 122A configured to extract information from thedata information file 111A; an information control wrapper logic 12Aconfigured to wrap the data information file with an information controlwrapper 134A. The multi-source health data integration logic may alsocomprise an information loader 126A. The multi-source health dataintegration logic 120A may be configured generate 120P cleaned andsovereignty wrapped data (transformed interoperable data). The systemmay include a staging database 130A configured to receive cleaned andsovereignty wrapped data (transformed interoperable data) from themulti-source health data integration logic 120A; said staging databasecomprising a plurality of staged records 131A. The staged records maycomprise an information control wrapper 134A configured to restrictusage of the data information; extracted information 132A in astandardized format; wherein the extracted information containselectronic health records; metadata 136A configured to provide detailsabout the extracted information; origin data 137A comprising sourceinformation of the extracted information; ownership data 138A comprisinginformation about what data provider owns the extracted information;encryption data 139A comprising information on how to encrypt theextracted information. The system 100A may comprise a pre-warehouselogic 140A configured to receive said staged records 131A from thestaging database; said pre-warehouse logic may comprise a codificationlogic 142A; a dimensionalization logic 144A; a conformation logic 146A;a consolidation logic 148A, and a transformation and alignment logic149A to transform and align related concepts; said transformation andalignment logic comprising a knowledge representation tool and ananalysis tool. The pre-warehouse logic 140A may be configured togenerate 140P transformed interoperable data warehoused in 141A. Thesystem may comprise a collaboration platform 150A configured to receivesaid warehoused data 141A. The warehoused data may be stored in datawarehouse 141B. The pre-warehouse logic 140A may further be configuredto generate 200P new sovereignty data arising from data transformation.

Referring to FIG. 24, the collaboration platform 150A may be configuredto provide: a derived concept market 151A containing warehoused data141A stored in a data warehouse 141B in common conformed dimensions. Thecollaboration platform may comprise one or more bridges 152A connectinga transformed component data 210 a, transformed additional source data212A, hosted telecollaboration interoperable data 214A, and transformedthird party models 216A.

Referring back to FIG. 23, the system may comprise an access interface160A configured to make said warehouse data accessible to a user 161A.

As shown in FIG. 25, the access interface 160A may comprise: an appmarket place 330A; a graphic user interface 340A; and a softwaredevelopment kit 300A. As shown in FIG. 23, the warehouse data may beaccessible to the first data provider 110A via the access interface160A.

The first data provider may comprise a computer. The computer maycomprise a tangible computer readable data storage device for storing,in a non-transitory manner, electronic personal health information andelectronic source specific permission and conditions data; a tangiblecomputer memory for storing of set of computer readable instructions; anetwork interface configured to facilitate communication between thefirst data provider and the multi-source health data integration logic;and a microprocessor configured to execute the computer readableinstructions.

The system 100 may comprise a server. The server may comprise a tangibleserver readable data storage device for storing, in a non-transitorymanner, the staging database; a tangible server memory for storing ofset of server readable instructions including the multi-source healthdata integration logic; and a microprocessor configured to execute theserver readable instructions. The server may comprise a tangible serverreadable data storage device for storing, in a non-transitory manner,the collaboration platform and warehoused data; a tangible server memoryfor storing of set of server readable instructions including thewarehouse logic; and a microprocessor configured to execute the serverreadable instructions. The system may comprise a plurality of dataproviders . . . a second data provider 110B is shown in FIG. 23.

Referring to FIG. 25, the system may comprise an access interface 160A.The access interface may comprise an app market place 330A, graphic userinterface 340A, and an SDK 330A. The app market place 330A may compriseuser apps 331A and third party apps 332A. The graphic under interface340A may comprise a homepage 341A and widgets 342A. The softwaredevelopment kit 300A may comprise natural language processing tools311A, statistical tools 312A, data visualization tools 313A, relationand collaboration tools 314A, geospatial tools 315A, artificialintelligence, machine learning, and deep level modeling tools 316A,policy operationalization tools 317A, gaming scenario tools 318A, queryengines 319A, project & task management tools 320A, import and exporttools 321A, and data integrity and security tools 322A.

Referring to FIG. 26, an exemplary system is shown comprising a datasource 400A comprising a data provider 110A and multi-source health dataintegration logic 120A; a staging database 130A comprising stagedrecords 131A. Said staging database may receive data from the datasource 400 a through a data pipelines 400P. The data source 400A mayreceive data back from analytics and AI engine 420A through a primarydata requirements feedback loop 401P. The data source 400A may beconfigured to adjust its primary data 402A based on the primary datarequirements feedback loop 401P. The system may comprise aninteroperability mapper 410A configured to map data from the stagingdatabase 130A using at least one of an automated mapping process 415A ora manual mapping process 416A. The system may comprise an analytics andartificial intelligence engine 420A configured to receive and providefeedback regarding data mapped for interoperability 411P to and from theinteroperability mapper 410A. The analytics and artificial intelligenceengine 420A may comprise a neural network 422A; data plot generator424A; and an integrated phenotype reference model 426A. The datapreparation logic 120A may receive data back from the analytics andartificial intelligence engine through a nested sovereignty feedbackloop 421P. The system may comprise an access interface 160A configuredprovide access to the integrated phenotype reference model 426A. Theaccess interface 160A may receive actionable information 420P from theanalytics and artificial intelligence engine 420A. The interoperabilitymapper 410A may be configured to receive data back from the accessinterface 160A through a feature engineering requirements feedback loop431P. The analytics and artificial intelligence engine 420A may beconfigured to receive data back from the access interface 160A through autilization patterns feedback loop 441P. The analytics and artificialintelligence engine 420A may be configured to adjust neural network 422Asettings based on the utilization patterns. The data source 400A may beconfigured to receive data back from the analytics and artificialintelligence through a feature engineering requirements feedback loop;said data source may adjust data elements included in provided recordsbased on the feature engineering requirements.

FIG. 27 shows an exemplary system comprising: a data provider 110Aconfigured to provide data in a data format; a data use agreementgenerator 512A configured to check whether the data provider 110A has anexisting data use agreement 510A in place; and if not, generating a datause agreement 513P for the data provider. The system may comprise apolicy generator 514A configured to setup policy-based schedules andtriggers 515P; an encryption logic 516A configured to encrypt data &manage keys 517P for data from the data provider. The system maycomprise a data format determination logic 521A configured to receiveand determine a data format of the data sent by the data provider 110A.The data format selected from the list consisting essentially of:streaming 521A, user input 522A, scrape 523A, bulk load 524A and aspecified connection 525A. They system may comprise a data formatconverter 530A configured to convert the data from the data provider toa common input format based on the data format determined by the dataformat determination logic. The data format converter 530A may comprise:a continuous data processor 531A, a forms processor 532A, a crawlerprocessor 533A, a secure uploader 534A, and a source processor 535A. Thesystem may comprise a multi-source health data integration logic 120Aconfigured to generate prepared data based on received data converted bythe data format converter. The multi-source health data integrationlogic may comprise an information extractor 122A, transformation andalignment logic 149A, and an information loader 128A. The system maycomprise a preliminary staging database 520A configured to receiveprepared data from the multi-source health data integration logic. Thesystem may contain a data integrity manager 564A configured to maintainthe integrity of data in the preliminary staging database. The dataintegrity manager 546A may comprise a structure detector 542A and a datatype corrector 544A. The system may comprise an information controlwrapper logic 124A configured to wrap the data from the preliminarystaging database, apply the data use agreement, and encrypt the data.The system may comprise a staging database 550A configured to receiveand store data from the information control wrapper logic. The systemmay comprise a phenotype engine 600A configured to receive data from thestaging database. The system may comprise a collaboration platform 150Aconfigured to receive data from the phenotype engine 600A. The phenotypeengine 600A may comprise a behavior model 625A configured to receiveutilization patterns from the collaboration platform 150A. The phenotypeengine 600A may be configured to receive data from an external datasource 518A. The external data source 518A may be configured to receiveencrypted data from the encryption data logic.

FIG. 28 illustrates a phenotype engine 600A. The phenotype engine maycomprise a plurality of reference sources 610A. The first referencesource 611A and second reference source 612A may comprise referencedata. The phenotype engine 600A may comprise a reference data processor620A comprising: a natural language processor 621A, phenotype processor622A, artificial intelligence data processor 623A, and interoperabilityprocessor 624A. The phenotype processor may be configured to generate anintegrated phenotype reference model (see FIG. 12B, 1220). The systemmay comprise a reference data processor 620A configured to access abehavior database 625A and an interoperability map 626A. The phenotypeengine 600A may comprise a reference database 630A configured to receiveprocessed data from the reference data processor 620A. The referencedatabase 630A may comprise syntax data storage 631A, phenotype datastorage 632A (for storing the integrated phenotype reference model1220), deep learning data storage 633A, and dimension data storage 634A.The phenotype engine 600A may comprise an output generator 640Aconfigured to output data. The output generator 640A may comprise aninformation retriever 641A, workflow support 624A, pattern detector643A, predictive modeler 644A, data visualizer 645A, and user experienceoptimizer 646A. The phenotype engine may comprise a code repository 650Aconfigured to receive output date from the output generator. Thephenotype engine may comprise a collaboration platform 150A connected toan access platform. The collaboration platform 150A and access platformmay be configured to provide access to the output data to a user. Theinteroperability processor 624A may configured to receive utilizationand pattern data 660P from the collaboration platform 150A. The firstreference 610A of the phenotype engine may comprise a first set ofterminology, ontology, and encoding data, and the second referenceincludes a second set of terminology, ontology, and encoding data. Thereferences may comprise an information exchange standardized modelreference. The first reference may include a set of medical terminology,ontology, and encoding data, and the second reference may include a setof laboratory terminology, ontology, and encoding data. The behaviordatabase 625A may comprise user data, input and behavior data, socialnetwork performance, and social network characteristics. The dimensiondata storage 634A may comprise common confirmed, fuzzy, and crispdimension data. The syntax data storage 631A may comprise textannotation, indexing, winnowing, and accruing corpus characteristicdata. The phenotype data storage 632A may comprise an integratedphenotype reference mode. The deep learning database 633A may comprisedeep learning and machine learning data. The information retriever 641Amay be configured to perform information retrieval and push processing.The workflow support 642A may be configured to provide clinical decisionsupport and workflow support. The pattern detector 643A may beconfigured to provide pattern detection and anomaly detection. Thepredictive modeler 644A may be configured to generate spatiotemporalpredicative models. The data visualizer 645A may be configured toprovide data visualization and manipulation tools. The user experienceoptimizer 646A may be configured to optimize user experience and providecollaboration tools. The phenotype engine may comprise a referencesource, wherein the reference source is a computer database. Thedatabase may contain a microprocessor, storage media, system memory,computer executable code, and networking hardware; said computerexecutable configured to cause the reference source to provideinformation to the reference database processor. The phenotype enginemay comprise a server. The server may comprise a microprocessor, storagemedia, system memory, computer executable code, and networking hardware.The computer executable code may be configured to cause themicroprocessor to implement the reference data processor, outputgenerator, and collaboration platform.

FIG. 29 illustrates a data modeler 1A that may be configured collect,prepare, aggregate, update, share, protect, and generate a model 1B(such as an integrated phenotype reference model 1220, see FIG. 12B) forusers to access to improve their ability to conduct research and improveperformance and accuracy of their research and/or services. In someconfigurations, the data modeler updates its generated model 1B (e.g.integrated phenotype reference model) based on the queries and accesspatterns of its users. The data model may be based on underlying data1C. In some configurations, the data modeler 1A may comprise: a datapreparation system 100A comprising data preparation logic 120A; stagingdatabase 130A for storing prepared data as staged records; phenotypeengine 600A for generating a model such as an integrated phenotypereference model; pre-warehouse logic 140A for transforming,consolidating, conforming, dimensionalizing and codifying stagedrecords; a collaboration platform 150A for storing warehoused data 141A;and an access interface 160A for providing access to the warehoused dataand integrated phenotype reference model. In an example, the datamodeler may be configured to collect the provider data, prepare theprovider data, aggregate the provider data, update the warehoused data,share the warehoused data, protect the warehouse data, and generate anintegrated phenotype reference model for users to access and conductresearch via access interface.

FIG. 32 shows a schematic diagram of the data modeler 1A with detailsremoved to show the entire modeler in one figure. FIG. 32 basicallyrepresents an exemplary configured of FIGS. 17, 18, 19, and 20 in asingle combined figure. Machine learning feedback data 32A, automatedpipeline self-modification processing 32B, policy and standardsrepository 32C, policy and standards editor 32D are shown. Some exampleelements are included to help with understanding of this figure such1812 (text annotation, indexing, windowing, and accruing corpuscharacteristics), phenotype processing 1822, data lake 1702, informationretrieval and push processing 1826, derived market concept 1902, anddata warehouse and collaborative network 1900.

Some aspects of the data modeler 1A do not need interoperability withevery last data element. In some cases, the data modeler 1A finds andaligns concepts such as medical and public health (MPH) concepts andrelevant law enforcement (LE) concepts. The integrated phenotypereference model may create a pattern language, rather than a dictionaryper se, of the key concepts in medical and public health & lawenforcement that can be cognitively manipulated, analogous to businessconcepts like customers or products or regional markets in othercontexts.

The integrated phenotype reference model 1220 may be analogized to linkcharts & evidence boards which are popular in law enforcement televisionshows. A core phenotype may be one of the concepts on the board with athumbtack and strings coming and going. In the integrated phenotypereference model, each core phenotype may then also include somesatellite concepts that are related and frequently co-occur within therecords. The “integrated” part of the integrated phenotype referencemodel may refer an association of medical, public health, and lawenforcement sharing the same model. In some cases, their concepts andsatellites overlap one another in a large network.

As an example, the medical and public health concept of opioid overdosehas related satellite concepts such as heroin, fentanyl, needleexchange, transdermal, unconscious, naloxone, and myriad street names,but the phenotype may also include law enforcement concepts such asdealer and transnational cartel, etc. Other core concepts in theintegrated phenotype reference model, such as the Sinaloa Cartel, couldhave overlapping satellites, such as a transnational cartel, and thesatellites could then help to connect opioid overdose with the SinaloaCartel.

Consolidation logic (FIG. 23, 149A) may be configured to find andconsolidate data that is to be aligned. The data lake 114 can havedifferent kinds of contextual data and other models, and not all of itwill always need alignment. Consolidation generally involves records,such as medical and law enforcement records in the data lake.Transformation and alignment logic may be used to align the coreconcepts within those records. FIG. 4 shows a consolidate step 412Awhich performs similar functions as the consolidate logic (FIG. 23,149A).

Conformation logic (FIG. 23, 146A) may be configured to analyze sourcerecords to determine whether they are relevant to a recognizedphenotype, optionally, within a degree of certainty. In other words, theconformation logic is where a source record is determined to be talkingabout a recognized phenotype, within a degree of certainty. Theconformation logic is where the pre-warehouse logic 140A may indexoriginal data records (e.g. adding metadata) to the relevant phenotypein the integrated phenotype reference model, provide a degree ofcertainty, and tag evidence within the record (e.g., the words orphrases) that was used for the determination. FIG. 4 shows aconfirmation step 412B which performs similar functions as theconfirmation (FIG. 23, 146A).

In an example, if the data preparation system 100A were processing arecord that included unconscious and naloxone, but nothing else, thepre-warehouse logic 140A, FIG. 23 or multi-source health dataintegration logic FIG. 1, 102 may index the record as a possible opioidoverdose, with a certain confidence interval (e.g. 65% confidence), andtag or highlight those two words (unconscious and naloxone) in therecord. Continuing the example, another record in the data warehouse141B may contain information regarding unconscious and fentanyl. Thepre-warehouse logic may similarly index to the opioid overdosephenotype, but with a lesser degree of confidence (e.g. maybe only 50%confidence.) In this example, the data preparation system 100A or themulti-source health data integration logic FIG. 1, 102 has conformedoriginal disparate records into the same reference model. Suchconformation facilitates data aggregation and/or data modeling. Therebyproviding enhanced functional interoperability without manual mapping.

Dimensions are concepts the data modeler 1A may use within a model suchas integrated phenotype reference model 1220, whether a core concept ora satellite concept. In aggregate, the dimensions may form a lexicon ofwords, phrases, lab tests, medications, diagnosis codes, etc., includingsynonyms and near synonyms, and including multilingual variants.Dimensionalization logic is configured to dimensionalize (providedimensionalization) dimensions. Dimensionalization may including taggingof the content or dimensions that the dimensionalization logicrecognizes. Dimensionalization may be performed to facilitateconformation.

Codification logic 142A (or archive logic) may be configured to archiveor store results (e.g. generate archived data) from the transformationand alignment logic 149A. E.g. the codification logic 142A may store howwe got what we got out of the alignment process. If the data preparationsystem 100A, FIG. 23 (multi-source health data integration logic 102,FIG. 1) made a misidentification, or missed an important identification,the archived data generated by the codification logic 142A may providesufficient information for the phenotype processor to rebuild theintegrated phenotype reference model. The phenotype processor 622A maybe configured to rebuild a part of the integrated phenotype referencemodel 1220 using the archived data. The phenotype processor 622A may beconfigured to analyze archived data and determine how a mistakeoccurred. In some embodiments, situations, codification logic willencode the archived data, rather than simply saving all the integratedphenotype references models and original data. The codification logic142A may be configured to store enough information in that archived dataso that the data preparation logic may rebuild the model (e.g. anintegrated phenotype reference model) without having to save it in itsentirety.

Rules of engagement may include a wrapper (e.g. a rules of engagementwrapper). In some examples, a rules of engagement wrapped is derivedfrom the data use agreement (513P, FIG. 27). A rules of engagement datawrapper may determine how the data within the wrapper may be used. Forexample, the rules of engagement data wrapper may control which parts ofthe data (attribute-based access controls), by whom (role-based accesscontrols), and under which circumstances (context-based accesscontrols). Coupled with persistent encryption and provenance meta-data(explained below), these variables help construct a zero trust system.In some configurations, even a true zero-trust system may be developed.This may be preferable to systems that just rely on checking the usercredentials (which are not true zero trust systems). Through thedeployment of true zero trust system, collaborators can be marketplacecompetitors or lack any mutual trust.

Persistent encryption relates to securing the data itself, not just theperimeter of the data modeler 1A. In some configurations, persistentencryption embodiments may include system-wide persistent encryption . .. encryption that persists through the data modeler 1A.

Provenance may include a wrapper (e.g. a provenance wrapper). Data witha provenance wrapper may provenance information. Provenance informationmay provide the data modeler 1A with information concerning source ororigin of the data. Data in the data preparation system 100A may beprovided by data providers 110A. The provenance wrapper may indicate whothese data providers are. Provenance information may be existent even inaggregated states. Provenance wrappers and/or provenance information maybe used by data preparation logic 120A, phenotype engine 600A and othercomponents of the data modeler 1A. Provence information may be used bythe data modeler 1A to track and correct misinformation, disinformation,and malinformation throughout the data modeler and/or integratedphenotype reference model. Many modeling techniques in modern datascience, particularly deep learning models, are nonlinear and candisplay chaotic dynamics (exquisite sensitivity on initial conditions).Such system may be vulnerable to data doping, which relates to intakinga dataset that has critical errors in it; critical errors designed todisrupt modeling in a way that is very difficult to discern. Trackingprovenance allows the data modeler 1A to find all the data from apotential corrupted source, even when it has been aggregated andsubsumed within integrated phenotype reference model, and reverseengineer its effects. The data modeler may comprise malicious dataanalyzer (FIG. 28) configured to detect misinformation, disinformation,and/malinformation. The data analyzer may be configured to use theprovenance wrapper and/or provenance information to identify a source ofthe malicious data. The data modeler may comprise a model repair engineto remove and/or repair the malicious data. The malicious data analyzer660A and model repair engine may be configured to interface with thecode repository 650A, the collaboration platform 150A, or the data lake.

Sovereignty wrapping relates to the summary effect of rules ofengagement, encryption, and provenance. Sovereignty wrapping provides adata owner with control (in some case absolute control) of their data.Data wrapped with a sovereignty wrap (e.g. including rules ofengagement, encryption, and provenance) may be controlled by the dataowner even if the data is removed from the data modeler 1A.

Dynamic policy operations (702G in the SDK of FIG. 7, 317A in FIG. 25)may provide nuance to the sovereignty. Granular access controls based onrole and data attributes tend to evolve over time, depending on context,potentially dynamically in sometime in the context of a crisis, forexample. Dynamic policies manage the evolving access requirements inreal time by applying role- and attribute-based policies in accordancewith the changing context.

FIG. 30 illustrates a schematic diagram of data sovereignty wrapping700A. FIG. 30 illustrates a data cloud 701A. “Nested Sovereignty” (seeFIG. 31) extends the nuance even further. Data is element 701A.Analytics is elements 702A. Models is elements 703A. Nested sovereignty710A may be generated by feedback loop (122, FIG. 1 or 190P FIG. 23).Nested sovereignty may recognize different equities represented acrossthe original data, the preliminary analytics, and the data's inclusionin larger models. Each step may add new value and new ownership, andeach of the products may require sovereignty over that new value.Although shown below as a linear progression for clarity, the nestedrelationships can be branching.

As an example, imagine a patient arrives at the doctor's office for anappointment. The patient brings with them his/her demographics,complaints, and body. He or she should have complete sovereignty overthat data, now and into the future. Now the doctor sees the patient andadds a considerable amount of value: retrieves subtleties of thesymptoms, pulls out relevant aspects of the context, describes someastute physical findings, orders clarifying tests, and in the end,applies a label (diagnosis) to the situation. The patient does not ownthat work, the doctor does, but the patient still owns their originaldata. The doctor's data is irrelevant without the patient's, so theseare not parallel values, but nested values, hence the need to developnested sovereignty.

Continuing the example, now the data are pulled up by an analyst who hasbeen surveilling for the peculiar physical findings that the doctor hasrecorded. The analyst then aggregates with similar cases and does somebrilliant modeling that determines we have detected a new diseaseprocess, subtly buried in wrong diagnoses. Neither the patient nor thedoctor owns this new value, although they do retain the value that theycontributed. This notion of nested sovereignty has the effect ofallowing control over raw data to be independent of the control ofderivative data, as is needed when analysis on open-source data producesa classified result, for example.

As a side observation, nested sovereignty has the ability to create anew economic basis for medical data transactions: if the value ofmedical data can be controlled by its various owners, it can enter afree market where pharmaceutical companies, insurers, governments, andso own could purchase the data for their needs. In short, medical datacan be commoditized and traded. Patients might receive royalties for theuse of their data (think of the case of Henrietta Lacks), doctors canreceive royalties for the astuteness of their observations and thequality of their records (sloppy and irrelevant data are rampant acrossmedicine), and analysts could receive payment for the use of theirresults in improving the public's health. This is analogous to digitalrights management of products in the entertainment industry.

The data modeler 1A, generated model 1B, and model data 1C can helpunify medical and public health and law enforcement concepts usingdimensions (from the lexicon). The essence of making subtle or unusualconnections is that the data modeler 1A uses vector space to see what isin the neighborhood. Dimensions may be crafted precisely enough (despitepossible linguistic variations) to be relatively independent of allother dimensions. Then a record that has been dimensionalized (taggedwith all the dimensions found within it, each with an associated degreeof confidence).

A vector calculator (FIG. 23, 144B) may produce a vector where theamplitude of the vector is determined by the frequency (count) withwhich that dimension occurred within the record. The vector calculatormay include all dimensions together to create a vector for the record.The vector calculator may normalize the vector so that it has a totalvector length of 1.0. The vector calculator may determine the cosinebetween vectors, an arithmetic problem, that can be performed by thevector calculator on the fly computationally. Close concepts in aneighborhood would have the smallest cosines between their vectors (i.e,they necessarily have overlapping satellite concepts in the integratedphenotype reference model). As some dimensions may include some degreeof uncertainty, the vector that represents a record may be a bit fuzzy,so nearest neighborhood can be contextually tighter or looser. In FIGS.10 and 26, five feedback loops are illustrated. In some configurations,they may be designed a single process with multiple inputs and outputsalong with a storage capacity.

Referring to FIGS. 10 and 26, Loop 138 on FIG. 10 (441P on FIG. 26) goesfrom the GUI to the data warehouse and returns utilizationpatterns—which widgets and apps are getting the most use. Loop 130(431P) goes from the data warehouse/collaborative platform/AccessInterface 160A to the Analytics and AI Engine 420 and returns featureengineering and new phenotype connections. Loop 122 (421P) goes from theAnalytics and AI Engine 420 to the Data Source (400A) and adds nestedsovereignty information as analyses and models are built. Loop 123(401P) goes from the Analytics and AI Engine to the source data ownersand returns primary data requirements to them. FIG. 26 also shows afeedback loop, 411P, between the Analytics and AI Engine and theinteroperability mapping processes, which uses the feedback to helpspeed up the manual mapping and to help refine the computed integratedphenotype reference model mapping.

The collaboration platform 150A may be configured to tracks how usersbehave on the data model 1A. For example, users may be frequentlylooking at (querying, discussing in threads, using dashboards, etc) datathat have been indexed to two concepts that the integrated phenotypereference model didn't have connections between. The machine learningalgorithm flags a possible connection between the two concepts, but it'sassumed to start with. As the behavior pattern gets reinforced withongoing use, the machine learning presents the connection to thehumans-in-the-loop involved with the interoperability and phenotypingprocesses who can validate it and perhaps note details as to the natureof the connection. When the new connection is validated, it becomesapparent that the connection was evident to subject matter experts butnot intrinsic to the source data (otherwise the integrated phenotypereference model would already have detected the connection), so thehumans can provide feedback to the source data owners suggesting thattheir primary data is not capturing an important relationship thatsubject matter experts on the platform are needing/leveraging. Thisprovides an incentive to collect new source data or to modify (or cleanup) data that is otherwise relevant but was somehow getting lost. Thenet result is the new source data can be used to make the connectionevident to the integrated phenotype reference model algorithms, and theknowledge representation tightens up and becomes more relevant. This isan example of the human-machine collaboration intrinsic to thefunctioning of the platform—perhaps not unlike how the use of a car isinherently a human-machine collaboration.

Computer Program Product

A computer program product is an article of manufacture that has acomputer-readable medium with executable program code that is adapted toenable a processing system to perform various operations and actions.

A computer-readable medium may be transitory or non-transitory.

A transitory computer-readable medium may be thought of as a conduit bywhich executable program code may be provided to a computer system, ashort-term storage that may not use the data it holds other than to passit on.

The buffers of transmitters and receivers that briefly store onlyportions of executable program code when being downloaded over theInternet is one example of a transitory computer-readable medium. Acarrier signal or radio frequency signal, in transit, that conveysportions of executable program code over the air or through cabling suchas fiber-optic cabling provides another example of a transitorycomputer-readable medium. Transitory computer-readable media conveyparts of executable program code on the move, typically holding it longenough to just pass it on.

Non-transitory computer-readable media may be understood as a storagefor the executable program code. Whereas a transitory computer-readablemedium holds executable program code on the move, a non-transitorycomputer-readable medium is meant to hold executable program code atrest. Non-transitory computer-readable media may hold the software inits entirety, and for longer duration, compared to transitorycomputer-readable media that holds only a portion of the software andfor a relatively short time. The term, “non-transitory computer-readablemedium,” specifically excludes communication signals such as radiofrequency signals in transit.

The following forms of storage exemplify non-transitorycomputer-readable media: removable storage such as a universal serialbus (USB) disk, a USB stick, a flash disk, a flash drive, a thumb drive,an external solid-state storage device (SSD), a compact flash card, asecure digital (SD) card, a diskette, a tape, a compact disc, an opticaldisc; secondary storage such as an internal hard drive, an internal SSD,internal flash memory, internal non-volatile memory, internal dynamicrandom-access memory (DRAM), read-only memory (ROM), random-accessmemory (RAM), and the like; and the primary storage of a computersystem.

Different terms may be used to express the relationship betweenexecutable program code and non-transitory computer-readable media.Executable program code may be written on a disc, embodied in anapplication-specific integrated circuit, stored in a memory chip, orloaded in a cache memory, for example. Herein, the executable programcode may be said, generally, to be “in” or “on” a computer-readablemedia. Conversely, the computer-readable media may be said to store, toinclude, to hold, or to have the executable program code.

Creation of Executable Program Code

Software source code may be understood to be a human-readable,high-level representation of logical operations. Statements written inthe C programming language provide an example of software source code.

Software source code, while sometimes colloquially described as aprogram or as code, is different from executable program code. Softwaresource code may be processed, through compilation for example, to yieldexecutable program code. The process that yields the executable programcode varies with the hardware processor; software source code meant toyield executable program code to run on one hardware processor made byone manufacturer, for example, will be processed differently than foranother hardware processor made by another manufacturer.

The process of transforming software source code into executable programcode is known to those familiar with this technical field as compilationor interpretation and is not the subject of this application.

User Interface

A computer system may include a user interface controller under controlof the processing system that displays a user interface in accordancewith a user interface module, i.e., a set of machine codes stored in thememory and selected from the predefined native instruction set of codesof the hardware processor, adapted to operate with the user interfacecontroller to implement a user interface on a display device. Examplesof a display device include a television, a projector, a computerdisplay, a laptop display, a tablet display, a smartphone display, asmart television display, or the like.

The user interface may facilitate the collection of inputs from a user.The user interface may be graphical user interface with one or more userinterface objects such as display objects and user activatable objects.The user interface may also have a touch interface that detects inputwhen a user touches a display device.

A display object of a user interface may display information to theuser. A user activatable object may allow the user to take some action.A display object and a user activatable object may be separate,collocated, overlapping, or nested one within another. Examples ofdisplay objects include lines, borders, text, images, or the like.Examples of user activatable objects include menus, buttons, toolbars,input boxes, widgets, and the like.

Communications

The various networks are illustrated throughout the drawings anddescribed in other locations throughout this disclosure, can compriseany suitable type of network such as the Internet or a wide variety ofother types of networks and combinations thereof. For example, thenetwork may include a wide area network (WAN), a local area network(LAN), a wireless network, an intranet, the Internet, a combinationthereof, and so on. Further, although a single network is shown, anetwork can be configured to include multiple networks.

CONCLUSION

For any computer-implemented embodiment, “means plus function” elementswill use the term “means;” the terms “logic” and “module” have themeaning ascribed to them above and are not to be construed as genericmeans. An interpretation under 35 U.S.C. § 112(f) is desired only wherethis description and/or the claims use specific terminology historicallyrecognized to invoke the benefit of interpretation, such as “means,” andthe structure corresponding to a recited function, to include theequivalents thereof, as permitted to the fullest extent of the law andthis written description, may include the disclosure, the accompanyingclaims, and the drawings, as they would be understood by one of skill inthe art.

To the extent the subject matter has been described in language specificto structural features or methodological steps, it will be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or steps described. Rather,the specific features and steps are disclosed as example forms ofimplementing the claimed subject matter. To the extent headings appearin this description, they are for the convenience of the reader, not aslimitations or restrictions of the systems, techniques, approaches,methods, or devices to those appearing in any section. Rather, theteachings and disclosures herein can be combined or rearranged withother portions of this disclosure and the knowledge of one of ordinaryskill in the art. This disclosure generally encompasses and includessuch variation. The indication of any elements or steps as “optional”does not indicate that all other or any other elements or steps aremandatory. The claims define the invention and form part of thespecification. Limitations from the written description are not to beread into the claims.

Certain attributes, functions, steps of methods, or sub-steps of methodsdescribed herein may be associated with physical structures orcomponents, such as a module of a physical device that, inimplementations in accordance with this disclosure, make use ofinstructions (e.g., computer executable instructions) that may beembodied in hardware, such as an application-specific integratedcircuit, or that may cause a computer (e.g., a general-purpose computer)executing the instructions to have defined characteristics. There may bea combination of hardware and software such as processor implementingfirmware, software, and so forth, to function as a special purposecomputer with the ascribed characteristics. For example, in embodimentsa module may comprise a functional hardware unit (such as aself-contained hardware or software or a combination thereof) designedto interface the other components of a system such as through use of anapplication programming interface (API). In embodiments, structures fora module a module can be according to the module's function or set offunctions, e.g., in accordance with a described algorithm. Thisdisclosure may use nomenclature that associates a component or modulewith a function, purpose, step, or sub-step to identify thecorresponding structure which, in instances, includes hardware and/orsoftware that function for a specific purpose.

While certain implementations have been described, these implementationshave been presented by way of example only and are not intended to limitthe scope of this disclosure. The novel devices, systems and methodsdescribed herein may be embodied in a variety of other forms;furthermore, various omissions, substitutions, and changes in the formof the devices, systems and methods described herein may be made withoutdeparting from the spirit of this disclosure.

What is claimed is:
 1. A data modeler for generating a model comprising:a first data provider configured to provide a data information file; adata preparation logic configured to receive said data information filefrom the first data provider; said data preparation logic configured togenerate transformed interoperable data; said data preparation logiccomprises: an information extractor configured to extract informationfrom the data information file; an information control wrapper logicconfigured to wrap the data information file with a control wrapper; atransformation and alignment logic configured to transform and alignrelated concepts; said transformation and alignment logic comprising aknowledge representation tool, and an analysis tool; and an informationloader; a staging database configured to receive transformedinteroperable data from the data preparation logic; said stagingdatabase comprising a plurality of staged records; a pre-warehouse logicconfigured to receive said staged records from the staging database;said pre-warehouse logic configured to generate warehoused data; saidpre-warehouse logic comprising: codification logic, dimensionalizationlogic, conformation logic, and consolidation logic; a collaborationplatform configured to receive said warehoused data; said collaborationplatform comprising: a derived concept market containing warehoused datain common conformed dimensions; and a bridge to provide transformedcomponent data, transformed additional source data, hostedtelecollaboration data, and transformed third models; an accessinterface configured to make said warehoused data and model accessibleto a user; and said warehoused data accessible to the first dataprovider via the access interface.
 2. The data modeler of claim 1wherein the first data provider is a computer comprising: a tangiblecomputer readable data storage device for storing, in a non-transitorymanner, electronic personal health information and electronic sourcespecific permission and conditions data; a tangible computer memory forstoring a set of computer readable instructions; a network interfaceconfigured to facilitate communication between the first data providerand the data preparation logic; and a microprocessor configured toexecute the computer readable instructions.
 3. The data modeler of claim1 comprising a server; said server comprising: a tangible serverreadable data storage device for storing, in a non-transitory manner,the staging database; a tangible server memory for storing a set ofserver readable instructions including the data preparation logic; and amicroprocessor configured to execute the server readable instructions.4. The data modeler of claim 1 comprising a server; said servercomprising: a tangible server readable data storage device for storing,in a non-transitory manner, the collaboration platform and warehouseddata; a tangible server memory for storing of set of server readableinstructions including the pre-warehouse logic; and a microprocessorconfigured to execute the server readable instructions.
 5. The datamodeler of claim 1 comprising a second data provider and a phenotypeengine for generating an integrated phenotype reference model.
 6. Thedata modeler of claim 1 wherein the access interface comprising: an appmarket place; a graphic user interface; and a software development kit.7. The data modeler of claim 1 further configured to collect the datainformation file, prepare data information file, aggregate the datainformation file, update the warehoused data, share the warehoused data,protect the warehoused data, and generate an integrated phenotypereference model for users to access and conduct research via accessinterface.
 8. The data modeler of claim 6 wherein: the app market placecomprises user apps and third party apps; the graphic user interfacecomprises a homepage and widgets; and the software development kitcomprises natural language processing tool, statistical tools, datavisualization tools, relation and collaboration tools, geospatial tools,artificial intelligence, machine learning, and deep level modelingtools, policy operationalization tools, gaming scenario tools, queryengines, project & task management tools, import and export tools, anddata integrity and security tools.
 9. A system comprising: a data sourcecomprising a data provider and data preparation logic; a stagingdatabase comprising staged records; said data source receiving data backfrom the staging database through a primary data requirements feedbackloop; an interoperability mapper configured to map data from the stagingdatabase using at least one of an automated mapping process and a manualmapping process; an analytics and artificial intelligence engineconfigured to receive data mapped for interoperability from theinteroperability mapper; and said staging database configured to receivefeature engineering requirements data back from the analytics andartificial intelligence engine through a feature engineeringrequirements feedback loop.
 10. The system of claim 9 wherein saidstaging database is configured to: receive data from the data sourcethrough a data pipeline; adjust the staged records based on the featureengineering requirements data; and adjust its primary data based on theprimary data requirements feedback loop.
 11. The system of claim 9wherein said analytics and artificial intelligence engine comprises aneural network; data plot generator; and an integrated phenotypereference model.
 12. The system of claim 11 comprising an accessinterface configured to provide access to the integrated phenotypereference model.
 13. The system of claim 12 wherein said accessinterface is configured to receive actionable information from theanalytics and artificial intelligence engine.
 14. The system of claim 13wherein said analytics and artificial intelligence engine is configuredto receive utilization patterns data back from the access interfacethrough a utilization patterns feedback loop.
 15. The system of claim 14wherein said analytics and artificial intelligence engine is configuredto adjust neural network settings based on the utilization patternsdata.
 16. A system comprising: a data provider configured to providedata in a data format; an encryption logic configured to encrypt datafrom the data provider; a data format determination logic configured toreceive and determine a data format of the data sent by the dataprovider; a data format converter configured to convert the data fromthe data provider to a common input format based on the data formatdetermined by the data format determination logic; a data preparationlogic configured to generate prepared data based on received dataconverted by the data format converter; a preliminary staging databaseconfigured to receive prepared data from the data preparation logic; anda phenotype engine comprising a behavior model.
 17. The system of claim16 comprising: a data use agreement generator configured to checkwhether the data provider has an existing data use agreement in place;and if not, generating a data use agreement for the data provider; apolicy generator configured to setup policy-based schedules andtriggers; an information control wrapper logic configured to wrap thedata from the preliminary staging database, apply the data useagreement, and encrypt the data; and a staging database configured toreceive and store data from the information control wrapper logic; aphenotype engine configured to receive data from a staging database; anda collaboration platform configured to receive data from the phenotypeengine.
 18. The system of claim 16 wherein said data format is selectedfrom the list consisting essentially of: streaming, user input, scrape,bulk load and specified connection.
 19. The system of claim 16 whereinsaid data format converter comprises: a continuous data processor, aforms processor, a crawler processor, a secure uploader, and a sourceprocessor.
 20. The system of claim 16 wherein said data preparationlogic comprises an information extractor, transformation and alignmentlogic, and an information loader.
 21. The system of claim 16 comprisinga data integrity manager configured to maintain data integrity in thepreliminary staging database; said data integrity manager comprising astructure detector and a data type corrector.
 22. The system of claim 16wherein said phenotype engine is configured to receive data from anexternal data source; and said external data source configured toreceive encrypted data from the encryption logic.
 23. A phenotype enginecomprising: a reference data processor comprising: a natural languageprocessor, phenotype processor, artificial intelligence data processor,and interoperability processor; the reference data processor configuredto access a behavior database and an interoperability map; a referencedatabase configured to receive processed data from the reference dataprocessor; said reference database comprising syntax data storage,phenotype data storage, deep learning data storage, and dimension datastorage; an output generator configured to output data; said outputgenerator comprising an information retriever, workflow support, patterndetector, predictive modeler, data visualizer, and user experienceoptimizer; a code repository configured to receive output data from theoutput generator; a collaboration platform connected to an accessplatform; said collaboration platform and access platform configured toprovide access to the output data to a user; and the interoperabilityprocessor configured to receive utilization and pattern data from thecollaboration platform.
 24. The phenotype engine of claim 23 comprisinga first reference source including a first set of terminology, ontology,and encoding data, and a first reference source including a second setof terminology, ontology, and encoding data.
 25. The phenotype engine ofclaim 23 comprising a first reference source including a set of medicalterminology, ontology, and encoding data, and a second reference sourceincludes a set of laboratory terminology, ontology, and encoding data.26. The phenotype engine of claim 23 wherein: the behavior databasecomprises user data, input and behavior data, social networkperformance, and social network characteristics; the dimension datastorage comprises common confirmed, fuzzy, and crisp dimension data; thesyntax data storage comprises text annotation, indexing, winnowing, andaccruing corpus characteristic data; the phenotype data storagecomprises an integrated phenotype reference model; and the deep learningdata storage comprises deep learning and machine learning data.
 27. Thephenotype engine of claim 23 comprising a plurality of reference sourcescomprising reference data.
 28. The phenotype engine of claim 23comprising a reference source; wherein the reference source is acomputer database containing a microprocessor, storage media, systemmemory, computer executable code, and networking hardware; said computerexecutable code configured to cause the reference source to provideinformation to the reference data processor.
 29. The phenotype engine ofclaim 23 comprising a server; wherein the server comprises amicroprocessor, storage media, system memory, computer executable code,and networking hardware; said computer executable code configured tocause the microprocessor to implement the reference data processor,output generator, and collaboration platform.
 30. The phenotype engineof claim 23 wherein: the information retriever is configured to performinformation retrieval and push processing; the workflow support isconfigured to provide clinical decision support and workflow support;the pattern detector is configured to provide pattern detection andanomaly detection; the predictive modeler is configured to generatespatiotemporal predicative models; the data visualizer is configured toprovide data visualization and manipulation tools; and the userexperience optimizer is configured to optimize user experience andprovide collaboration tools.